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SEKTION 5 
Sprachaspekte und künstliche Intelligenz 


Klaus Ahrens 


" SIMULATIONSTERKZEUGE IN MODULA-2, " 


Die Anwendung der computergestütsten Simulation entwickelt 


sich 


immer mehr zu einer notwendigen Voraussetzung in Ent- 


wurfsprozeß konplexer Syotene, Dabei spielen in den letzten 
Jahren in verstärkten Maße Rechnersystene selbst als Unter- 
suchungs- und Entwurfsobjekte eine wichtige Rolle. Zu den 
Faktoren, die diese Tendenz beschleunigen, gehören vor allen 
folgende: 


(9) 


(2) 


Die explosive Entwicklung des Hardwaresektors ist Aus- 
gengspunkt einer weitreichenden Anwendung von Oonpatern 
zur Steuerung realer Prozesse. In den Entwurf derartiger 
Steuerungssystone sind sowohl Hardware als auch Software 
integriert. Der Entwurf geht also nicht mehr nur von 
einer festen Hardware aus und untersucht alternative 
Softwarelösungen, sondern bezicoht die Suche nach optina- 
len Hardwarekonfigurationen mit ein. Damit ergibt sich 
für die Simulation die Forderung nach solchen Simulations- 
systemen, die diesen Aspekt mit berücksichtigen, Inden 
sie Experinente mit unterschiedlichen Software-, Hard- 


“ ware- und Lastmodellen ermöglichen, 


Im Zusammenhang mit dem ersten Faktor steht die Forderung 
nach einen notwendigen Vorlauf in der Softwareentwicklung. 
Mit dem Entmurf der Programme für neue Rochnerkonfigura- 
tionen kann nicht erst begonnen werden, wenn diese ver- 
fügbar sind. Im Gegenteil muß die Softwareerstellung unab- 
hängig von Fragen der Verfügbarkeit der Zielhardware 
unterstützt werden, so daß eine weitgehend ausgetestete 
Software und die entsprechende Hardware möglichst gleich- 
zeitig verfügbar werden. In Cross-Entwicklüängssystemen 
dieser Art wird die Simlation insbesondere dann unum- 
eänglich, wenn es über eine bloße Emilation der Zielma- 
schine hinaus un eine Einbeziehung von Modellen realer 
Prozesse bzw. um die Ableitung quentitativer Aussagen 
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über das dynamische Systemverhalten geht. 


(3) Die Forderung nach zuverlässigen Steuerungssystenen, die 
überdies auch eine leichte Wartung und Portabilität un- 
terstützen, führt zwangsläufig dazu, deß auch in der 
Systenprogrammierung die traditionellen Assemblerspra- 
ehen zunehmend von modernen höheren Programniersprachen 
abgelöst werden. Dabei erhebt sich jeddach sofort die 
Frage nach resultierenden Uneffektivitäten. Die Simla- 
tion muß Mittel bereitstellen, die die Engpässe derarti- 
ger Systene in höheren Programniersprachen lokalisierbar 
machen, so daß in jedem konkreten Fall entschieden werden 
kann, ob und welche Teile des Gesantsystens nmaschinennah 
zu implenentieren sind, um den Anforderungen (insbesonde- 
re Zeitanforderungen bei Realzeit-Anwendungen) gerecht zu 
werden: , 

Eristierende Simulationssystene werden diesen neuen Anforde- 
zungen nur in unzureichenden Maße gerecht (GPSS- Familie). 
Auch wenn sie zun Teil die Modellerstellung und -untersuckung 
von Haräware- und Softwarekomponenten unterstützen, ermögli- 
chen sie für uns keinen direkten Übergang von Softwarenodellen 
zur eigentlichen Implementation der Software. (Simula-OASIS /4/) 
Die leichte Überführbarkeit von realen Inplementationen von 
Programmen zu entsprechenden Modellen und umgekehrt ist jeddch 
eine entscheidende Voraussetzung für einen integrierten Inple- 
nentations- und Similationsprozeß im Entmurf moderner Steue- 
zungssoftware, die insbesondere dann gegeben ist, wenn beide 
Phasen in einer Sprache erfolgen. | 


Ansgehend von dieser Analyse wurde in der Forschungsgruppe 
"Simulation" am Bereich Informationsverarbeitung der Humboldt- 
Universität Berlin untersucht, inwieweit die Sprache Modula-2 
/3/.ein geeigneter Ausgangspunkt für einen solchen integrier- 
ten Entwurfsprozeß ist. Diese Sprache wurde aus folgenden 
Gründen gewählt: 


- Modula-2 ist ursprünglich für die Systemprogrammierung auf 
Kleinrechnern entwickelt worden, erfüllt also den Implenen- 
tationsaspokt a priorl; 
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- Modula-2 enthält ein elementares Koroutinenkonzept, welches 
als Ausgangspunkt für die quasiparallele Modellierung 
paralleler Prozesse als geeignet erschien; 


- Die Sprache Modula-2 hat seit ihrer ersten Implementation 
an der ETH Zürich eine rasche Verbreitung und Anwendung 
gefunden, was sich sicherlich in Zukunft noch fortsetzen 
wird; 


- Modula-2 ist eine Pascal-ähnliche Sprache mit einer systema- 
- tischen Syntax, einem modernen Typkonzept und mit der 
Möglichkeit der separaten Übersetzung, wobei die Konsistenz 
der Schnittstellen durch Compiler überprüfbar ist; 
Somit wird sie dem Pascal-Programmierer leicht zugänglich, 
bietet zugleich aber eine geeignete Ausgangsebasis auf einen 
möglichen Weg zu Ada; 


- Modula-2 ist am Bereich Infornationsverarbeitung seit 1982 
auf K1620/1630 und seit kurzen auch auf Bürocompmuter ver- 
fügbar. 


Der erste Ansatz bei der Untersuchung von Modula-2 für die 
Simlation bestand in der Implementation eines allgemeinen 
Basissimlationssystens in dieser Sprache. Dazu bot sich als 
Vorbild die Simila-Klasse 'Simulation' /3/ an, da sie 


1. typische Konzepte eines prozeßorientierten Basissimla- 
tionssystens in sidh vereinigt, die auch Ausgangspunkt 
für Similationssystene in anderen Sprachen waren und sind 
(Pascal, Ada,..); 

2. als Basis für verschiedene Erweiterungen (Unterklassen) 
zu £achspezifischen Simulationssystemen verwendet wurde, 
die zum Teil auch in unserer Forschungsgruppe entwickelt 
‘wurden, so daß hier bereits einige fertige Systeng aber 
auch wesentliche Erfahrungen in der Softwaretechnologie 
für Simlationssysteme allgemein vorlagen. 


Um ein solches 'Simmlation'-Konzept auch in Modula-2 zu reali- 
sleren, mıßten zunächst die wesentlichen Unterschiede beider 
Sprachen hinsichtlich dieser Zielstellung erfaßt werden. 


Moäula-2 


dynanische Pointertypen 
Strukturen 


ebstrakter 
Datentyp Moduln 


- Koroutinen Prozeduren 


Ein- und - 
Ausgabe (Streams, InOut) 


Mexrtverar- Strings 


hierarchische 


Erweiterungen (EXPORT / IMPORT) ee 


( dabei bedeutet '-', daß entsprechende Konzepte fehlen, bzw. 
nur bedingt, als zu erweiternde Basiselemente vorhanden sind) 


Es zeigt sich, daß der universelle Charakter der Simla- 
Klassen kein adäquates Modula-2 -Gegenstück hat, so daß einige 
Grunäkonzepte neu zu überdenken waren. Die folgende Übersicht 
gibt lediglich eine Skizze der allgemeinen Vorgehensweise, die 
bei der Implementation verfolgt wurde. Auf eine eingehende 
Dokumentation der Erstellung des Moduls "'SIMULATIOR! soll hier 
verzichtet werden (entsprechende Ausführungen sind in /4/ zu 
finden): | 


Simla Modula=2 
prooess Simprocess 


class 


(Einheit von 
Attributen und 
Anweisungen ) 


Anweisungen 
(Koroutine 
PROC ) 
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Für die Modula-2 Umsetzung eines Prozeßbegriffs der älskreten 
Sirulation nacht sich also eine Aufspaltung in beschreibende 
Daten (Pointertyp auf ein Recorä, welches die Attribute eines 
Prozesses, sowie ein besonderes Feld des Typs PROCESS enthält) 
und in den Anweisungsteil erforderlich, Dadurch ist og nöglich, 
die Dynamik von Prozessen auch in Modula-2 aufrecht zu erhalten 
und zugleich die Koroutinen (PROOESB) zu verwenden, Die Ver- 
bindung beider Komponemten eines Prozenses (Simprocess) erfolgt 
bei soiner Erzeugung durch die Prozedur 'NewSIMPROCESS', 


In Ergebnis den ersten Ansatzes der Nutzung von Modula-2 für 
die diskrete Simulation entstand der Modul "'SIMULATION', dessen 
Definitionesmodul hier in Auszügen folgt. 


DEFINITION MODULE Simlation; s 
EXPORT GQUALIFIED ...(z allo definierten Objekte m)...; 


TYPE Simprocoss; (z hidden =) 
VAR Main: Sinprocess;z 


PROGEDURE Hold (Tı REAL); (= verzögert den aufrufenden 
Sinprooess un die Zeit 'T'! m) 

PROCEDURE Paseivate; (z verzögert den aufrufenden Simpro-. 

zess Tür unbestimmte Zeit (er wird 
passiv) 2) 
PROCEDURE Current (): Simprocess; (z liefert den aktuellen 
' Sinmproeoss =) 

PROGEDURE Tine (): REAL; (= berechnet die aktuelle Sirmm- 

lationszeit =) 


PROCEDURE Activate (SIMP: Sinprocess); (= aktiviert SIMP =) 


PROCEDURE ActivateAT (SIMP: Simproress; T: REAL 
PRIOR: BOOLEAN); (z aktiviert SIMP 


zun Zeitpunkt 'T! mit der Priorität 
PRIOR =) 


PROCEDURE NMeuSIMPROOESS. (BODY: PROC; n: CARDINAL):Simprocess; 


(3 erzeugt einon neuen Sinmprocess mit den 
Anweisungsteil BODY und mit einen Arbeits- 
speicher der Größe 'n'! ) 


END Simlation. 
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Die zweite Stufe der Untersuchungen bestand in der Implenenta- 
tion eines fachgebletsorientierten Simulationssystens in 
Modula-2. Entsprechend der globalen Zielstellung der simlati- 
ven Unterstützung des Entwurfsprozesses von Rechmersysteonen 
wurde dabei ein solches Syaten erstellt, welches spezielle Bau- 
steine für die Modellierung in diesen Bereich bereitstellt. 
Auch hier kam die Anregung aus der Sprache Simla, in der uns 
das System OASIS vorlag, das für diesen Zweck geeignet er- 
schien. Da OASIS selbst eine Unterklassoe von 'Sirmlation' ist, 
war der Versuch, ein analoges System in Modula-2 zu implenen- 
tieren zugleich eine Anwendung des Moduls "SIMULATION! in der 
sich die Tragfähigkeit der entwickelten Konzepte erweisen 
konnte. Das System OASIS besteht in seiner Sirula-Inmplementa- 
tion in wesentlichen aus einer Sammlung von elementaren Bau- 
steinen, so daß es sich für eine Dekomposition in Modula-2 
unter Nutzung separater Moduln eignet. Deu gesente Simulations- 
systen ist von relativ geringen Umfeng. Seine Konzeption liogt 
gerade in der Bereitstellung einfacher, aber erweiterungsfähiger 
Grundelemente, die typische Komponenten von realen Rechner- 
systemen modellmäßig repräsentieren. 


Unter Nutzung des Moduls 'SIMULATION' wurde das Systen 


OASIS-M2 implementiert, das sich aus folgenden Bestandteilen 
(separate Definitions-/Implenentationenoduln) zusammensetzt: 


- MODULE frenme : Experinentinitialisierung und 

5 , =abschluß; 

- MODULE reports : Routinen für die Datensammlung 
-aufbereitung und -ausgabe; 

- MODULE devices t Basistyp für Geräte mit ent- 
sprechenden Routinen; 

- MODULE me=oryhandling sı Basistypen zur Modeilierung 
von Speichermedien; 

- MODULE modulehandling s Basistyp für Prozessoren und 
Programme mit entsprechenden 
Beziehungen. 


l 


Auf den Weg zu einen integrierten Entwurfsprozess für 
Modula-2 -Steuerungssoftware ist das hier vorgesteiklte 
Simulationssysten OASIS-U2 sicher mur ein erster Schritt, 
Weitere Untersuchungen müssen vor allen in zwei Richtungen 
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'weiterverfolgt werden: 
(1) Modifikation und Welterentwicklung des OASIS-M2-Ansatzes, 
um die Spezifik der Sprache Modula-2 als Systemprogran- 
mierungssprache besser zu berücksichtigen und auszumutzen; 


(2) Verfolgung weiterer möglicher Ansätze der Simulation, die 
nicht auf next-event-scheduling Algorithmen beruhen und 
somit Bereitstellung eines ganzen Systens von Similations- 
werkzeugen in einer Modula-2-Programmierungebung. 
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Der ESER-C-Compiler unter PSU 

° 
Systemsoftware unterliegt extremen Anforderungen hinsichtlich 
Kodeeffizienz, Zuverlässigkeit, Wartungsfreundlichkeit sowie 
in zunehmendem Maße auch hinsichtlich der Übertragbarkeit auf 
andere Rechnerarchitekturen. 
Moderne höhere Programmiersprachen unterstützen die Entwicklung 
gut strukturierter, zuverlässiger und portabler Programne. Trotz- 
dem wird insbesondere in der Systemprogrammierung auch noch ge- 
genwärtig vor allen auf Grund geringeren Speicherplatzbedarfes 
und günstigeren Laufzeitverhaltens oft auf Ässenmbler zurückge- 
griffen, obwohl damit erhebliche Nachteile, wie verlängerte 
Programmentwicklungszeiten usw. verbunden sind. 

Die Programmiersprache C wurde 1972 von Dennis.M. Ritchie 
entworfen und implementiert. Sie bietet eine leistungsfählge 
Schnittstelle zur Hardware und stellt geeignete Mittel zur 
Entwicklung portabler und kodeeffizienter Programme zur Ver- 
fügung. Ein Grundprinzip von C besteht darin, dem Programmierer 
bei der Wahl der sprachlichen Mittel möglichst wenig Restrik- 
tionen aufzuerlegen. Die damit verbundene Flexibilität kommt 
vor allem bei der Implementation von Systemsoftware zum Tragen. 
Andererseits wird. dadurch vom Programmierer ein hohes Maß an 
Disziplin und Sorgfalt gefordert, insbesondere bei der Verwen- 
dung externer Variabler und im Umgang mit Zeigern, 

Im Zusammenhang mit dem Betriebssystem UNIX findet die 
Sprache C international wachsende Verbreitung. C-Compiler 
existieren mittlerweile für die -unterschledlichsten Rechner- 
architekturen über die gesamte Breite von Mikrorechnersystemen 
bis zu Hochleistungsrechnern, 

Die Entwicklungsarbeiten an einem C-Compiler für ESER-Anla- 
gen werden seit lNitte 1984 auf Grundlage einer Kooperations- 
vereinbarung zwischen der TH Karl-Marx-Stadt und dem LfA Berlin 
weitergeführt. Ab 1/85 ist der Compiler zur Erprobung freige- 
geben und bisher an 8 Hochschuleinrichtungen installiert. 
Außerhalb des NHF kann eine Vorabnutzung mit dem LfA Berlin 
vereinbart werden. 


Die Hauptbestandteile Bes Döner sind der Präprozessor, 
2 Übersetzungspässe, Optimierungspaß und die Standard-E/A-Bib- 
liothek, die auch die Schnittstelle zum Filemanager der PSU /1/ 
bereitstellt. Der realisierte Sprachumfang entspricht der 
C-Sprachbeschreibung von Kernighan und Ritchie /2/. Darüber- 
hinaus wurden Strukturzuweisungen und der Aufzählungstyp in das 
Sprachkonzept aufgenommen. Die C-Compiler für 16-Bit-Systeme in 
der DDR (K1630, SKR, U8000, ACS) haben bzw. werden den gleichen 
Sprachumfang realisieren. Hierzu finden Abstimmungen zwischen 
den. Entwicklern statt, um den Softwareaustausch zu erleichtern. 


Entwicklungsproblene 


Für den ESER-C-Compiler sind auf Grund des stark abweichenden 
Maschinenbefehlssatzes einige Besonderheiten zu beachten. 


- Einzelfunktionen können durch Basisregisteradressierung bei 
Verwendung eines Registers nur 4K groß sein, Diese Begren- 
zung ist selten problematisch. Falls erforderlich, kann der 

Programmierer zusätzliche Basisregister vereinbaren. Die An- 
zahl der möglichen Registervariablen wird dadurch reduziert. 


- Da in C häufig mit externen Variablen gearbeitet wird, kann 
der Programmierer solche Variablen mit dem Schlüsselwort 
common direkt adressierbar machen. 

Mit Hilfe der Präprozessorsteuerung sind in beiden Fällen 
Portabilitätsprobleme vollständig vermeidbar. 


- Die Mehrfachdefinition nichtinitialisierter Variabler ist 
in C nicht verboten. Das Syntaxprüfprogramm lint /3/, das 
unter anderem Portabilitätsproblene aufspürt, erkennt einen 
solchen "saloppen!" Programmierstil. R r 
Bei SKR-Maschinen erfolgt die Speicherplatzvergabe nach 
initialisierten (.DATA) bzw. nichtinitialisierten Variablen 
(.BSS). Der Programmverbinder realisiert die gewünschte Zu- 

“ordnung und der Lader initialisiert die verbleibenden Be- 
reiche zu Null, wie es vom Sprachstandard gefordert wird. 
Die bisher verwendeten OS-Komponenten Assembler, Verbinder 
und Lader lassen eine solche Vorgehensweise nur mit Kompro- 
nissen zu. 

Endgültig und effektiv sind diese Probleme nur durch einen 
speziellen Assembler, Programmverbinder und Lader lösbar. 
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Codeoptimierungen 
Ein Ziel der C-Programmierung ist es, möglichst effektive 
Maschinenprogramme zu erhalten. Darauf wird an verschiedenen 
Stellen Einfluß genommen. 


- Der Programmierer kann bereits auf Quelltextebene das Code- 
verhalten beeinflussen. Beim ESER-C-Compiler kann man bis zu 
6 Variable pro Funktion direkt im Register halten. Insbeson- 
dere bei Zeiger auf Strukturen und Felder sind dabei Code- 
effektivierungen zu erwarten. Registervariable bringen im 
Vergleich zu automatischen Variablen auch keine zusätzliche 
Stackbelastung, was sich insbesondere bei ‘stark rekursiven 
Funktionen vorteilhaft auswirkt. 2 j 
Jeder Ausdruck besitzt einen Wert. Außerdem können Wertzuwei- 
sungen wie gewöhnliche Ausdrücke verwendet werden. Die sich 
daraus ergebenden Möglichkeiten Zur kompakteren Schreibweise 
unterstützen den Prozeß der Codeoptimierung. 


- Die Codegenerierung basiert auf dem Sethi-Ullmann-Algorith- 
mus /4/. Dabei erfolgt eine Vielzahl von Optimierungen auf den 
Ausdrucksniveau. Die Ausdrücke, die in Form von Binärbäumen 
vorliegen, werden untersucht und erforderlichenfalls umge- 
stellt und vereinfacht. Die Fähigkeiten der Maschine zur 
Adreßbildung auf der Basis von Registerinhalten und Offsets 
werden dabei weitestgehend ausgenutzt. 


- Wahlweise ist eine Optimierung auf Assenblerniveau 
(peephole-Optimierung /5/) möglich. 
Dabei werden z.B. Sprünge zu Sprüngen und überflüssige Lade- 
befehle beseitigt sowie Adressierungen vereinfacht. 

Zur Optimierung wird eine vollständige Funktion herangezogen. 
Die bisherigen Tests führten zu Codeverbesserungen von 5-10%. 


Erfahrungen beim Softwaretransport 


Im Verlauf des yergangenen Jahres wurden an der MLU Halle, 
der KMU und der TH Leipzig sowie der TH Karl-Narx-Stadt 

ca. 40 Programme aus dem Betriebssystem MUTOS 1630 /6/ in die 
PSU transportiert. Weiterhin realisierte das LfA Berlin die 
Entwicklung des Optimierungspasses für ESER im Systen 

.MUTOS 1630. Der anschließende Transport in die PSU erwies 
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sich als problemlos. Zu den implementierten Komponenten gehören 
auch solche komplexen Werkzeuge wie nroff, yacc, lex, sort, n4, 
sed und die grep-Familie. 
Der Übertragungsaufwand kann wie folgt klassifiziert werden: 


- Programme, die mit der Absicht des Transportes auf andere 
Maschinen geschrieben wurden (z.B. yacc und lex), braucht man 
nur neu zu Übersetzen. Der lint ist ein Werkzeug zur Unter- 
stützung dieser Absicht, 


- Manche Programme nehmen direkt auf die Maschinenarchitektur 
Bezug (z.B. integrale Grenzen, Adreßgröße). Solche Probleme 
müssen "nur" erkannt werden und sind dann leicht korrigier- 
bar. Mitunter sind solche Abhängigkeiten in define-Anweisun- 
gen des Präprozessors enthalten. 


- Bei einer weiteren Gruppe von Programmen ist der Algorithmus 
an den ASCII-Zeichensatz gebunden. So sind z.B. bei nroff 
und sed im freien 8. Bit Steuerinformationen untergebracht. 
In solchen Fällen ist es meist erforderlich, die Algorithmen 
sorgfältiger zu analysieren. 
Eine Lösungsmöglichkeit dieses Problems besteht darin, pro- 
grammintern im ASCII-Zeichensatz zu arbeiten. Dieser Weg 
wurde beim nroff gewählt. Zu beachten ist dabei die notwen- 
dige Umstellung von Zeichenkonstanten in eine binäre ASCII- 
Darstellung. 
Bei komplexen Algorithmen erscheint dieser Aufwand vertretbar. 
Eine alternative Möglichkeit stellt die Änderung der Programn- 
logik dar. 
Eine Abschätzung des für die Lösung derartiger Probleme not- 
wendigen Aufwandes kann nicht allgemein angegeben werden. 


Weitere Arbeiten 


Ende 1985 wird der ESER-C-Compiler unter PSU einschließlich 
der Komponenten lint und make /3/ zur produktiven Nutzung 
bereitgestellt. Der Vertrieb erfolgt durch den VEB Lfa Berlin. 
Darüberhinaus laufen Arbeiten zur Entwicklung eines in C ge- 
schriebenen und in die PSU integrierten Assemblers sowie Pro- 
grammverbinders. Um die Softwareentwicklung auch in der Phase 
der interaktiven Programmtestung zu unterstützen, sind in 
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einer weiteren. Etappe Entwicklungsarbeiten zur Bereitstellung 


einer zu adb /3/ vergleichbaren Komponente vorgesehen. 

Ein wichtiger Aspekt besteht in der Untersuchung von Sprach- 
erweiterungen. In der Literatur werden hierzu verschiedene Arbeil- 
ten vorgestellt, so z.B. die Realisierung des Class- bzw. des 
Modulkonzeptes /7/, /8/ und die Bildung abstrakter Datentypen /9/. 
Andere Konzepte werden in /10/ und /11/ diskutiert. Die Sprach- 
erweiterungen werden i.a. durch Präprozessoren realisiert und 
stehen damit dem Programmierer wahlweise als zusätzliche Werk- 
zeuge bei der Softwareentwicklung zur Verfügung. 
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Grabowski, Jan 


Konzept für einen Silicon-Compiler 


1. Silicon-Compiler 


Gegenwärtig wird weltweit an. durchgängig rechnergestützten Verfahren 
zum Entwurf hoch- und höchstintegrierter Schaltkreise gearbeitet, Dabei 
spielen u. a, folgende Kriterien eine Rolle: 

(1) Resultat des Verfahrens ist eine vollständige, verifizierte Layoüt- 
beschreibung. 

(2) Das Verfehren wird vom Nutzer über eine einheitliche Nutzerschnitt- 
stelle gesteuert, bestehend etwa aus einer Steuersprache, struktu- 
zellen und funktionellen Beschreibungsmitteln, einer Datenbasis von 
Standardbausteinen und deren Eigenschaften sowie aus entsprechenden 
Nachrichten, die auf dem Niveau dieser Schnittstelle interpretiert 
werden können, also nicht auf abgeleitete Datenstrukturen bezug neh- 
men. | 

Ein Entmurfsverfahren, das diesen beiden Kriterien genügt, wird heute 

verschiedentlich als "Silicon-Compilation" bezeichnet, (vgl. /1/) Die 

Analogie zum Compiler einer höheren Programmiersprache ergibt sich vor 

allem aus. der Bedingung (2), die den Benutzer vom Umgang mit den im Ent- 

wurfsprozeß erzeugten Zrischen- und Endresultaten befreit (vgl. /2/). 

Eine strengere Analogie zum Compiler würde sich ergeben, wenn Bedingung 

(2) verschärft wird zu: i 

(3) Die Nutzereingabe besteht im wesentlichen aus einer Beschreibung des 
von der Schaltung zu realisierenden Algorithmus sowie wenigen, auch 
vom naiven Nutzer in ihren Wirkungen leicht überschaubaren "Pragmas" 
(Steusrungsoptionen, die die Semantik nicht beeinflussen). 

Ein Silicon-Compiler mit den Eigenschaften (1) - (3) ist potentiell ge- 

eignet für den nichtprofessionellen Anwender; damit kann das Entwerfen 

von Schaltkreisen eine vergleichsweise leichte Aufgabe werden, ähnlich. 
wie der Einsatz von hüheren Programmiersprachen das Programmieren zu ei- 
ner leichten Aufgabe gemacht hat. Voraussetzung ist bier wie dort, daß 
der Preis, der in Form unvermeidlicher Effizienzverluste gezahlt wird, 
als nicht zu hoch angesehen wird, 
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2. Höhere Beschreibungssprachen für integrierte Schaltkreise 
Bedingung (3) weist der Hardwarebeschreibungssprache (HDL) einen wesent. 
lichen Platz im Entmurfsinstrumentarium ein. Es gibt schon eine anseh- 
liche Zahl von Hardwarebeschreibungssprachen; in jüngster Zeit geht das 
Bestreben dahin, VLSI-fähige HDL’s zu entwickeln /3/. Einige dieser 
Sprachen unterscheiden sich nur punktuell von höheren Programierspra- 
chen, z. B. CHISEL /a/, MIMOLA /5/. Ein notwendiger Unterschied besteht 
dort, wo 
- Konstruktionen weggelassen werden, die gich nicht in Hardware überset- 
zen lassen (dynamische Variablel), 
- die Ausdrucksmöglichkeiten für Parallelität in angemessener Weise er- 
weitert werden, 
- Pragmas zur Steuerung des Entwurfsprozesses verwendet werden, 
Grundsätzlich erscheint es sinnvoll, insbesondere die Konzepte von hö. 
beren Programmiersprachen auf HDL'!s zu übertragen, die den objektorien- 
tierten und modularen Entwurf unterstützen. Ein schönes Beispiel einer 
solchen HDL ist ZEUS /6/. 


3. Die Sprache TDSL 


An der Humboldt-Universität wurde ein Konzept für eine Hardwarebeschrei- 
bungssprache TDSL (top-domn silicon language) vorgestellt /7/. Dabei 
wurden folgende Merkmale angestrebt: 

- Beschreibungsmittel für parallele Signalflüsse, 

- Prozedur- und Datenabstraktion, 
- Modularität, 

- parameterabbängige Typen, 

- rekursive Übersetzung,’ 

- Lokalität der Datenübergabe. 
Eine einfache Anweisung von TDSL hat die Form 


x 


c—y:=x ed ; ö 
Hierin sind y und x gewöhnliche Variable, und c und d sind Variable des 
Typs control. Letztere sind verantwortlich für die Ablaufsteuerung; sie 
verhalten sich wie die Plätze in einem Petri-Netz, d. h. jede control- 
Variable kann nur den Wert true annehmen; bei Abarbeitung der obigen An- 
weisung verliert c ihren Wert, und d bekommt einen Nert, 
Anweisungen, die durch Semikolon getrennt sind, sind. zur parallelen db 
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arbeitung bestimmt; benutzen sie gemeinsame control-Variablen, so kön- 
nen Konflikte entstehen, die dadurch gelöst werden, daß eine der Anwei- 
sungen nicht aktiviert wird; in 

bi, comy:maxzed; 

b2, c=y ı= xee; 
kann z. B. stets nur eine der beiden Anweisungen ausgeführt werden, 
An Stelle einer Menge von Anweisungen kann ein Prozeduraufruf geschrie- 
den werden, der auf eine an anderer Stelle gegebene Prozedurdefinition 
Bezug niermt; in Prozedurdefinitionen verwendete Variable sind entweder 
lokale Variable oder in-Parameter oder out-Parameter; zwei ausgezeich- 
nete Variable entry und retury von Typ control sind als in- bzw. out-Pa- 
rameter stets implizit vorhanden, Wird z, B. die Prozedur 

procedure p(in x, out y: boolean) 
durch eine Anweisung 

entry-— A— return 
definiert, so ist ein Aufruf 

c—ep(x,y)—d 
äquivalent mit den drei Anweisungen 

c—— entry; 

entry ——A "return; 

return —d; 
Ein Modul ist eine verallgemeinerte Variable, die außer Variablen auch 
Prozeduren als Bestandteile enthält. zin Modul wird in einer Typdefini- 
tion erklärt. Beispiel einer Typdefinition: 

type box; 


procedure set; 
procedure res; 
procedure test(out t: boolsan); 


privat 
b: boolean; 
procedure set; 
- entry-—eb := true —-return; 
end set; 


procedure ros; 
entry -=b := false return; 
end res; 


procedure test(t); 
entry—t := b return; 
end test; 


end box 
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Ein Modul wird erzeugt, indem ein Objekt des Modultyps vereinbart wird; 
die Vereinbarung 
i bo: box 

erzeugt einen Modul des Typs box und ermöglicht z. B. einen Prozedurauf- 
ruf 

bo,set 
Im Unterschied zu Programmisrsprachen ist für TDSL wesentlich, daß man 
auf diese Neise mehrere Moduln eines Typs erzeugen kann, die dann vom 
Compiler in mehrere physische Einheiten transformiert worden, Jede Pro- 
zedur ist genau so oft physisch verfügbar, wie der Modul erzeugt würde, 
in dessen Typdefinition sie steht, 
Konstanten können in TDSL als Typparameter verwendet werden; so dezeich- 
net 

type register(const N: integer) = array[/ ..N- 1] of boolean 
einen parameterabhängigen Typ. Zur Übersetzungszeit müssen für alle Kon- 
stanten Werte eingesetzt bzw. berechnet sein. 
Laufanmeisungen werden zur Übersetzungszeit ausgewertet, z. B. bedeutet 

for i:=ßtoN-ideoyfi] :=x[i] od 
daß ein N-bit-Register-Transfer stattfindet, 
Rekursive Übersetzung kommt zustande, wenn die Definition eines (parane- 
terabhängigen) Typs sich selbst aufruft, Das folgende Beispiel zeigt ei- 
nen rekursiv zu übersetzenden Typ. 


4, Beispiel: Der rekursive Multiplizierer 


Der rekursive Multiplizierer multiplier(N) für zwei N-bit-Zahlen, wobei 
N eine Zweierpotenz ist, enthält vier Multiplizierer multiplier(N div 2), 
zwei Addierer, vier connect- und zwai shift-Moduln, (connect und shift 
werden nachstehend definiert. Der Addierer wird als bekannt vorausgese- 
tzt), 
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type bool(eonst N: integer) = azray[f .N- 1] ‚o£ boolean; 


type adder(oonst N: Integer); 
procedure ad(in x, yı bool(N), out z:bool(N)); 
private 


eo 


end adder; 


type oonneot(gonst N: Integer; const high: boolean); 
progedure co(in r: bool(N); out 8: bool(Ndiy 2)); 
private (# es folgt der nichtexportierte Teil von connect #) 
procedure co(r,s); 
entry 
for 1 = fßtoNdiv2-1do 
assume high; (X Fallunterscheidung zur Übersetzungs- 


sli] = rli+ N div 2]; zeit x) 
assume not high; 
ali] := r[i; 
endassums 
od 
»zeturn 
end co 
and conneot; 


type shift(sonst N: Integer); 
procedure sh(in r: bool(N); out 5: bool(N.* 2)); ‘ 


private 
procedure sh(r,3); 
eutıy = 
begin 
for-i := S'to Ndiv2-1de s[i] := false od; 
for i:=Ndiv2toN+Ndiv2-1do 
sli] := rli - naiv 2] oa; 
fori:= N+Ndiv2to2»N- 1do s[i] := false og; 
end 
—»return 
end sh 
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type multiplier(const N: Integer); 
procedure mu(in x, y: bool(N); out z: bool(N = 2)); 
private 


assume N > 1; 
addi, add2; adder(N * 2); 
mit: array[i .. 2, 1... 2) o£ multiplier(N div 2); 
shifti, shift2: shift(N); 
conni, conn2, connd, oonn4: ; Srmeetie 2 ; u); 
connS, conn6, conn?, connd: connect(N, f£ I) 
u,v: "errayli oo 2, 1 0. 2) of bool(N 2); 
w: arrayfi .. 2,1... 2,° of bool(N); 
r, si, s2, t: bool(N x 2 
di, d2, a3; control; 
1-7} d, 0 array [i .. 2, > 2) of control; 
procedure mı(z, y, z); 
entry — 
begin 
conni.co(x,.u (1,21) >a 1,1]; 
conn2.co(x, u,2])) -alt,2]; 
conn3.co(y, vß.1)) —) 1.1]; 
eonnd.co(y, v2,1]) —vR,1]; 
connd.co(x, uß1])—aß,1]; 
eonn6.co(x, uß,2])—aß,2); 
conn?, eo(y, v R2)) —b ß:.2); 
connd.co(y, vß,2))——d R.2); 
end; 
for i := 1 to 2 de 
for J := 1 to 2 do 
ali,j], vi, 
mut[i,3) mu(u[i,3], vi, N) "[1,3]) 


--o[i,3] 
nr 
ed; 
begin 
e[1,)— 


forkım ßPtoN-1de 
r[k + N] := w[1,1,%) od; 
e[2,2)— 
for k:=ftoB-- ide rk) := w{2,2,K] od; 
end di; . | 
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begin 
el1,2] shifti.sh(n[1,2], sı); 
o[2,1]® shift2.sh(w[2,1), s2); 
end->d2; 
d2—— addi.ad(s1, s2, t) a3; 
di, d3-madd2,ad(F, t, 2) return; 


end m; 
assume N = 1; 
procedure mu(x, y, 2); i 
sntıy 
z[6) := x[ß] ana y[f]; 2[11:= false 
—-sroeturn 
and my; 
endassume; 


end mıltiplier 


5, Prinzipien für den TDSL-Compiler 


Bisher standen die Gemeinsamkeiten zwischen Silicon-Sprache und Program- 
miersprache im Vordergrund der Betrachtung. Der ÜbersetzungsprozeB muß 
notwendigerweise erhebliche Unterschiede aufweisen, Ein Silicon-Compiler 
muß eine ungleich schrierigere Aufgabe bewältigen als ein Software-Com- 
piler. Er muß kritische Platz-, Zeit- und Energiebedarfsrestriktionen 
erfüllen. Diese Restriktionen stehen jeweils in unterschiedlicher eise, 
so daß für einen und denselben Typ an verschiedenen Stellen'iäm allgemei- 
nen ein unterschiedliches Ergebnis erzeugt werden muß. Die Verbindungs- 
moduln wie conni bis oonn8 in unserem Beispiel sind alle vom selben Typ, 
aber je nach Anschlußbedingungen müssen sie unterschiedlich übersetzt 
werden. ö 

Ferner ist die Verifikation des Ergebnisses ein wesentlich vielschich- 
tigeres Problem als in der Programmierung, da die Parallelität der Ab- 
läufe und die Einhaltung von Zeit- und elektrischen Toleranzen berük- 
ksichtigt werden müssen. Diese Aufgabe wird bisher nur durch heuristiseh 
gelenkten Einsatz verschiedener Analysetechniken bewerkstelligt. 

Der für die Sprache TDSL adäquate Compiler muß eine top-donn-Übersetzung 
realisieren. Das bedeutet: Beginnend mit dem Hauptmodul wird die Überse- 
tzung eines Moduls jeweils auf die Übersetzung seiner Teilmoduln und die 
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Schaffung der Verbindungen zurückgeführt. Im Normalfall wird jeder Modul 
dort neu übersetzt, wo er vorkommt, auch wenn ein Modul gleichen Typs 
schon früher übersstzt wurde. So wird die Anpassung an die lokal beste- 
henden Einschränkungen berücksichtigt. 
Mit dem top-down-Übersetzungsprozeß geht eine schrittweise Verfeinerung 
der Aufteilung der Chipfläche einher: Für jeden zu übersetzenden Modul 
wird ein Stück Chipfläche vorgegeben, an dessen Rand Anschlüsse plaziert 
sind. In dieser Fläche ist dep Zieloode unterzubringen, Der voraussicht- 
liche Platzbedarf eines Moduls wird bottom-up aus dem Platzbedarf seiner 
Teilmoduln berechnet. Turde er unterschätzt, so ist der Modul nicht über- 
setzbar; es ist ein höherer Platzbedarf zu veranschlagen, was eine Neu- 
übersetzung des übergeordneten Moduls erfordert. 
Das zweite wichtige Merkmal ist die Lokalität der Datenübergabe, Durch 
Sichtbarkeitsbeschränkungen für die Objekte im TDSL-Text wird erzwungen, 
daß bei der Übersetzung eines Teilmoduls nicht unvorhergesehen eine Ver- 
bindung zu einem sehr weit entfernten anderen Teilmodul gezogen werden 
muß. Die Sichtbarkeitsbeschränkungen bewirken, daß stets nur Daten zwi- 
schen direkt über- oder nebengeordneten Objekten unmittelbar übergeben 
werden. Sind Schaltzeiten: für die elementaren Vorgänge bekannt, so kann 
das Zeitverhalten schon aufgrund des Quelltextes grob abgeschätzt werden. 


6, Probleme 


Die Veröffentlichung eines Sprachkonzeptes kann, wie die Erfahrung lehrt, 
die Entwicklung von Compilern befördern, Im Fall der Silicon-Compiler 
ist der Weg allerdings besonders weit. 

Einige Fragen, die außerhalb jeder Betrachtung geblieben sind, werden 

hier genannt: 

1) das Problem der Aufteilung von Funktionen auf Hardwarekomponenten, 
z. B. die Zerlegung der Befehle eines programmierbaren Schaltkreises 
in Mikrobefehle, die jeweils von 6iner Komponente realisiert werden. 
Ganz allgemein gesprochen handelt es sich um das Problem der Mehr- 
fachnutzung von Moduln unter dem Gesichtspunkt der Platzbeschränkung. 

2) die Ausmahl geeigneter Grundfunktionen, die (technologieabhängig 7) 
als leicht zu realisierende Funktionen zur bevorzugten Verwendung 
empfohlen werden, 

'3) das Problem der Unterscheidung zwischen Variablen, die einen sta- 


5-21 
tischen Speicher benötigen, und kurzzeitig belegten Variablen, 
4) der Aufbau des Compilers aus Konstruktions- und Verifikations-, 
werkzeugen 
und vieles andere mehr, 


7. Literatur 


/1/ Daniel D. Gajski "THR STRUCTURE OF A SILICON COMPILER" 
“in Proc. IEEE Int. Conf. on Circuits aud Computers (New York) 1982 


/2/ Stephen C. Johnson "VLSI CIRCUIT DESIGN REACHES THE LEVEL OP ARCHI. 
PECTURAL DESCRIPTION" 
ELECTRONICS, May 3, D BA 


/3/ John F. Buckley "HIGHSLEVEL HARDWARE DESCRPTION LANGUAGES: A. NEM 
COMPUTER AIDED DESIGN TOOL" 
British Telecormunications Ehginsering Journal, Vol 2, Part 4, Jen. 
1984 


/4/ Jeffrey D. Ullman "COMPUTATIONAL ASPECTS OF VLSI" 
COMPUTER SCIENCEPRESS 1983 


/5/ Peter Marwedel ®THR MIMOLA DESIGN SYSTEM: A DESIGN SYSTEM WHICH 
SPANS SEVERAL LEVELS" 
in: #. Giloi (ed): "METHODOLOGIES FOR ‘COMPUTER SYSTEM DESION« ° 
North Holland, 1984 


/e/ Karl J. Lieberherr, Svend E, Knudsen "ZEUS: A HARDWARE DESCRIPTION; 
LANGUAGE FOR VLSI* 
Report, Eidgenössische Teehnische Hochschule Zürich, Institut.für 
Informatik, Februar 1983 


/U/ Jen Grabowski "GRUNDMERKMALE EINER QUELLSPRACHE FÜR TOP-DOMN- 
SILICON-COMPILER" 
ORZ der Humboldt-Universität zu Berlin, 1984, unveröffentlicht 


Dr, sc. Jan Grabowski 
Dipl. Math. W, Dietmar Gellermann 


Humboldt-Universität 

1086 Berlin 

Organisations-und Rechenzentrum 
PSP 12 97 


5-22 
Grabowski, Jan 
ORZ der Humboldt-Universität, DDR, 1086 Berlin, PSP 1297 
Hypothesenbildung in wissensverarbeitenden Systemen: Thesen und 
Implementationsbeispiele in PROLOG 


. Eypothesenbildende Systeme 
a, Systeme sollen Über die Fähigkeit ver- 


fügen, aus gespeichertem Wissen (Fakten, Gesetzen) Schlüsse 
zu ziehen, also weiteres Wiesen zu erzeugen, Häufig spielt 
dabei der Umstand eine Rolle, daß dem System unvollständige 
Informationen über einen Gegenstandsbereich mitgeteilt wurden, 
die diesen nicht systematisch, sondern nur exemplarisch be- 
schreiben. Mitunter liegt das einfach daran, daß der Benutzer 
überhaupt nicht in der lage ist, den Gegenstandsbereich systo- 
matisch zu beschreiben, \ 

Un geforderte Funktionen, z. B. Abfrageaufgaben, auf der 
Basis unvollständigen Wissens erfüllen zu können, muß mit- 
unter fehlendes Wissen durch eine Hypothese ersetzt werden. 
Ein wissensverarbeitendes System, das Über eine solche Mög- 
lichkeit verfügt, nennen wir hypothesenbildend. Die Hypothesen 
können falsch und die Reaktionen des Systens daher fehler- 
haft sein; es ist Sache des Benutzers, die Bildung falscher 
Hypothesen durch ein möglichst vollständiges Infornations- 
angebot aussuschließen bzw. beim Erkennen’ von Fehlern das 
Angebot entsprechend zu ergänzen, d.h. das Systen zu "be- 
lehren", Beispielsweise können die exemplarischen Informa- 
tlonen Beispielsätze einer Sprache sein, deren Syntax dern 
Systen zwar in Grundzügen bekannt ist, aber in Einzelheiten 
durch Auswertung der Beispiele ergänzt werden soll. 

Das System muß ggf. Hypothesen Über syntaktische Regeln auf- 
stellen, un einen Satz Überhaupt formulieren zu können. 

Ein anderes Beispiels Die unvollständigen Informationen mögen 
aus Input-Output-Beispielen einer Funktion bestehen, die”den 
Systen nur bis auf Zugehörigkeit zu einer Klasse von Funk=- 
tionen bekannt ist; das Systen muß ein hypothetisches Pro- 
gramn für die Funktion bilden, um weitere Funktionswerte 
vorberzusagen. 


3 
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Man mache sich klar, daß die "Belehrung" im allgemeinen 
nicht darauf hinauslaufen darf, daß der Benutzer alle von 
Systen gebildeten Hypothesen unnmittelber auf ihre Richtig- 
keit überprüft, denn diese können ihm unverständlich, zu 
kompliziert oder zu zahlreich sein. Wir betrachten daher 
den Fall der Belehrung durch Beispiele als den Nornalfell,. 


Hypothesen können permanent, d.h. wie Fakten oder Gesetze 

zur weiteren Verwendung gespeichert, oder temporär sein. 

Eine temporäre Hypothese wird nur zur Erfüllung einer ge- 
forderten Abfrageleistung gebildet und anschließend wieder 
vergessen. , 

Permanente Hypothesen können mit neu hinzukomzmenden Wissen 
in Widerspruch geraten (inkonsistent werden); wenn wir solche 
Hypothesen als unzulässig betrachten, so bedeutet dies, daß 
nach jeder Erweiterung des gesicherten Wissens alle Hypo- 
thesen von neuem auf ihre Konsistenz Überprüft werden müssen. 
Bei temporären Hypothesen entfällt dies. 


Unten soll die Arbeit mit temporären Hypothesen an einen Bei- 
spiel in der Sprache PROLOG dargestellt werden. 


2. Ein Bein 1el 
Wir stellen uns vor, daß das wissensverarbeitende Systen 


deutschaprachige Sätze analysieren, interpretieren und be= 
entnorten soll, Die Sätze nügen Uperationen Über einer sehr 
einfachen Datenbasis ausdrlicken, die aus einer zweistelligen 
Relation "element" besteht. Die Auunge 
"Die Katze ist ein Mer." 

nöge besagen, daß die Beziehung 

element ("Katze", "Tier") 
zutrifft. Ein korrekter Dialog nit dem Systen könnte so ab 
laufen: 
Benutzer: "Die Katze ist ein Tier." 
System: "Verstanden." 
Benutzer: "Ist die Katze ein Tier?" 
Systens "Ja," 
Benutzers "Ist die Gemae ein Tier?" 
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Systens "Nein." 
Benutzer: "Gibt os ein Tier?" 
Systen: "Ja," 
Benutzer: "Wer ist ein Tier?" 
Systens "Die Katze ist ein Tier." 


Richten wir unsere Aufmerksankeit auf den Teil des Wissens- 
erwerbs, der sozusagen neben dem inhaltsbozogenen Winsens- 
erwerb nebenher läufts den Erwerb der. Fähigkeit, deutsch- 
sprachige Sätze zu analysieren und zu »ilden,. Wir gehen da- 
von aus, daß die Konstruktionsregeln der vorkommenden Sätze 
bereits bekannt sind, die grammatikalischen Werknale der 
vorkonnenden Substantive aber durch Auswertung der Beispiel- 
sätze erst zu erlernen sind. 

Spätestens nach der Auswertung des Satzes "Die Katze ist 

ein Tier" steht fest, daß "Katze" ein weibliches und "Tier" 
ein nännliches oder säshliches Substantiv ist. Angenormen, 
das Systen 1U8t die unvollständige Information unberlick- 
sichtigt, speichert also "Tier" als Substantiv nit unbekann- 
ten Geschlecht, so int als Antwort auf die Frage "Wer ist 
ein Tier?" die syntaktisch falsche Antwort "Die Katze ist 
eine Tier" nöglich. (Bildung der Hypothese, daß "Tier" 
weiblich sei.) Angenommen, das Systen speichert als perma- 
nente Hypothese, daß "Tier" männlichen Geschlechts sei, so 
wird os auf die Frage "Gibt eo ein Tier?" vielleicht irr- 
tünlich mit "Hein" antworten, da "ein Tier" in dieser Frage 
ersichtlich nicht die Form eines männlichen Substantivse hat, 
die erfragta Information jedoch in Speicher nit einen nänn- 
lichen Substantiv verbunden int. Es bleibt also nichts anderes 
übrig, als auch unvollständige Informationen wie die, daß 
"Pler" ein männliches oder sächliches Substantiv ist, zu 
verwerten. 


3. Implementation des Beispieln 
Wir geben nun eine PROLOG-Inplementation für unsere Beispiel» 


Aufgabe an und achten dabei auf die Auswertung der unvoll- 
ständigen Information und die Bildung temporärer Hypothesen. 
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Wir halten uns bezüglich PROLOG an die Terminologie aus /1/ 
Der Frage-Antwort-Zyklus kann wie folgt hingeschrieben 
werdens 


(1) zykluss - prompot, /a Eingabeanforderung #/ 
lies (Satz) = 
interpretiere (Satz, Antwort), 
schreibe (Antwort). 


(Die nicht in Anfliheungszeichen eingeklammerten Buchstaben- 
ketten sind PROLOG-Atome (-Konstanten), falls sie 

mit einem Kleinbuchstaben beginnen, und sonst Variable. 
Wir behalten die Kleinschreibung auch im Text bei und heben 
dort die Atome und Variablen durch Unterstreichung hervor.) 
Die, Prozedur lies liefere den gelesenen Satz in Form einer 
Liste aus Zeichenketten, also ewwal"die", "Katze", "ist", 
"ein", "tier"]. " 

Die Prozedur interpretiere muß den Satz syntaktisch 

und semantisch analysieren, die. darin geforderte Operation 
ausführen und einen Antwortsatz synthetisleren. Wir be- 
ginnen mit dem Interpretieren eines "Wer-ist-Satzes": 


(2) interpretiere (Satz, Antwort) 
ı - neristsatz (Satz, Klasse), 
element (Element, Klasse), 
bilde _istsatz (Antwort, Element, Klasse), = 


(Es wird zunächst festgestellt, ob Satz ein "Wer-Ist-Satz" ist, 
also ein Fragesatz, der nach Elementen einer Klasse Klasse 
fragt. Wenn ja, so wird mit Hilfe von element ein Element der 
Klasse gesucht und der Variablen Element zugewiesen. Schließ- 
lich wird ein Satz gebildet, der aussagt, daß Element ein’ 
Element von Klasse ist.) 


(3) weristsatz (Satz, Klasse) 
$ - verketten C["wer" "ist" ], Klassenteil, Satz) 
substantivphrase (Klassenteil, Klasse, nominativ, 
unbestimmt). 


Klassenteil ist der auf "wer", "ist" folgende Teil von 
Satz. Klassentell muß eine substantivphrase mit dem Substantiv 
Klasse und dem unbestimmten Artikel im nominativ sein: 
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(4) substantivphrase ( [Wort 1, Wort 2], Substantiv, Fall, 
Artikeltyp), 
s — artikelform (Wort 1, Geschlecht, Fall, Artikeltyp), 
substantivform (Wort 2, Substantiv, Fall), 
not ‚(falsches_Geschlecht (Substantiv, Geschlecht)). 


-(5) artikelform ("ein", maennlich, nominativ, unbestimmt). 
(6) artikelform ("ein saechlich, nominativ, unbestimmt). 
.(7) substantivform (Wort, Wort, nominativ). 


Die Prozedur aubstantivphrase prüft nicht die exakte 
Übereinstimmung von Geschlecht mit dem Geschlecht des Sub- 
stantivs, da dieses möglichurmeise noch nicht eindeutig bekannt 
ist. Sie prüft lediglich, daß nicht "positiv bekannt" ist, daß 
Geschlecht nic,h t zum Geschlecht des Substantivs paßt. 
(Diese Information ist in falsches_Geschlecht gespeichert.) 


(8) bilde_istsatz (Antwort, Element. Klasse) 

ı - verketten (Elementteil, [ "ist" | Klassenteil] , Antwort), 
substantivphrase (Elementteil, Element, ROnINRSIyT> be- 
stimmt), 
substantivphrase (Klassenteil, Klasse, nominativ, un- 
bestimmt). 

artikelform (räier, weiblich, nominativ, bestimmt). 


Bei bilde_istsatz wird vermöge der Prozedur substantivphrase 
darauf gsachtetz daß äie Geschlechter der verwendeten Artikel 
den Geschlechtern der verwendeten Substantive nicht bekannter- 
maßen widersprechen. ‚Jede Artikelform, die diese Eigenschaft 
hat, ist ale Hypothese zulässig, um den Satz zu bilden. 

Wir behandeln nun die Auswertung eines "Ist-Satzes". 


(9) interpretiere (Satz, Antwort) 
‚= enalysiere_ Istsatz (Satz, Element, Klasse), 
merke (element (Element, Klasse)).- 
merke (Fakt) sei dabei eine Prozedur, die den Fakt: Fakt speichert, 
falls er noch nicht gespeichert ist, Außer dem Fakt element 
(Element, Klasse) sollen jedoch auch die neuen Fakten Über 
im Satz vorkommende Substantive gemerkt werden. Dies ge- 
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schieht in analysiere_Istsatzt 


(10) analysiere_Istsatz (Satz, Element, Klasse) 

t - verketten (Elementteil, "ist" | Klassenteil] ‚Satz), 
enalysiere_Substantivphrase (Elementteil, Element, 
nominativ, bestimmt), 
analysiere_Substantivphrase (Klassenteil, Klasse, 
nominativ, unbestimmt). 


(11) analysiere_Substantivphrase ([wort 1, Wort 2] ‚ Substantiv, 
Fall, Artikeltyp)' 
ı - substantivphrase ([Wort 1, Wort 2], Substantiv, 
Fall, Artikeltyp), 
asp (Wort 1, Substantiv, Fall, Artikeltyp). 


(12) asp (Wort, Substantiv, Fall, Artikeltyp) 
ı - not (artikelform (Wort, Geschlecht, Fall, Artikeltyp)), 
merke (£falsches_Geschlecht (Substantiv, Geschlecht)), 
fail, 


(13) asp (Wort, Substantiv, Fall, Artikeltyp). 

fail bedeutets Gehe zurück und probiere eine andere Regel. 
In unserem Falle heißt dası Suche einen weiteren Wert von 
Geschlecht, für den die Aussage 

not (artikelform (Wort, Geschlecht, Fall, Artikeltyp)) 
erfüllt ist, und merke auch hierfür den Fakt falsches_Ge- 
schlecht (Substantiv, Geschlecht). 

- Sind alle Möglichkeiten erschöpft, so tritt die zweite 
Regel für asp in Aktion, die zur sofortigen Beendigung der 
Prozedur asp führt. 


4. Gründe für eine Erweiterung der Sprache PROLOG 

Wie das obige Beispiel zeigt, eignet sich PROIOG sehr gut zur 
Programmierung des Erzeugens temporärer Hypothesen; als Hypo- 
thesen treten die während des Abarbeitens einer Anweisung 
temporär erzeugten Variablenbelegungen auf. Die Hypothese muß 
dabei Kontrollprozeduren passieren, die die Konsistenz prilfen; 
besteht eine Hypothese die Prüfung nicht, wird sie verworfen 
und sogleich die nlichst probiert. 
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Als Kontrollprozedur tri:t z. B. 


not (falsches_Geschlecht (Substantiv, Geschlecht)) 
auf. 
Die Relation falsches_Geschlecht wird aus Beispielen aufge- 
baut, ze B. liefert die Analyse von 
"Die Katze ist ein Tier" die Fakten 


(14) falsches_Geschlecht ( "Katze", maennlich). 
(15): falsches_Geschlecht ("katze", saechlich). 
(16) falsches_Geschlecht ("tier", weiblich). 


Die Erfahrung lehrt, daß die Auswertung unvollständiger In- 
formationen im Regelfall zu Ähnlichen Konstruktionen führt. 
Dem Wesen nach handelt es sich nämlich um Ungleichungen, wie 
wir sehen werden. 

Wir probieren eine andere Schreibweise für diese Konstruktion 
ausı Wir notieren die Regel (4) in der Form 


(4') substantivphrase ( [Wort 1, Wort 2], Substantiv, Fall, 
Artikeltyp) 
s - artikelform (Wort 1, @ geschlecht (Substantiv), Fall, 
Artikeltyp), 
substantivform (Wort 2, Substantiv, Fall). 
und die Fakten (14) - (16) in der Form 


(14) ®geschlecht ("katze") E weiblich. 
(16') ®geschlecht ("tier") % weiblich. 


Hier bezeichnet der mit N) beginnende Name ein in PROLOG ge- 
wöhnlich nicht vorkommendes Objekt, nämlich eine Funktion. 
Funktionen sind zu interpretieren als Abbildungen Über der 
Menge der PROLOG-Terme. Die Gleichung (11') und die Un- 
gleichung (13! ) besagen, daß die Funktion’® eschlecht, 
angewendet auf den PROLOG-Term "katze", den PROLOG-Tern 
weiblich liefert, dagegen bei Anwendung auf den PROLOG-Ter” 
"tier" einen von weiblich verschiedenen PROLOG-Tern, 
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Ein Term, dessen Funktor eine Funktion bezeichnet, möge 
nit einem zweiten Term genau dann unifizierbar sein, 
wenn die Ungleichheit beider nicht beweilsbar Ist, 
Demnach ist 
Ogeschlecht("tier") 
mit 
 maennlich 
unifizierbar, weil die Ungleichung 
Ogeschlecht("tier") maennlich 
nicht aus den bekannten Ungleichungen und Gleichungen herleit- 
bar ist. Also 
substantivphrase ( ["aer", "tier" ] ‚ "tier", nominativ, 
bestimmt) 
ist erfüllbar; dagegen ist 
substentivphrase ( Lrein", "katze"], "katze", nominativ, 
unbestimmt) 
nicht erfüllbar, 
Diese Erweiterung der Sprache PROLOG, die wir hier nicht ganz 
präzise und vollständig beschrieben haben (insbesondere sind 
wir den Ableitungsbegriff für Termunglelchungen, schuldig ge- 
blieben), paßt die Sprache noch besser den Erfordernissen der 
Auswertung unvollständiger Informationen en. Dies ergibt sich 
aus der großen Bedeutung, die Termungleichungen für die Hypo- 
thesenbildung beim Schließen aus unvollständiger Information 
haben (vgl. Jantke /2/). ’ 


5. Praktische Erfahrungen 

Am ORZ der Humboldt-Universität werden z. Zt. mit dem PROLOG- 
Interpreter IIUW-Prolog gesammelt. (IIUW-Prolog wurde am In- 
stitut für Informatik der Universität Warschau in PASCAL 360 
für ESER-Anlagen programmiert.) Die vorliegenden Erfahrungen 
betreffen die Arbeit mit Datenbanken, die deutschsprachige 
Konversation und insbesondere das Schließen aus unvollständigen 
Informationen, Es ist beabsichtigt, die in 4. vorgeschlagene 
Erweiterung der Sprache an diesem Interpreter vorzunehmen und 
zu erproben. 
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Hartwig,M.; Strobel,R.; Stein,E, 


Ober die Implementierung einer Teilmenge von Ada 


Die Programmiersprache Ada hat ale mögliche Basis einer 
einheitlichen Software-"echnologie starke Beachtung gefun- 
den. 


Am ZKI der ADW wird gegenwärtig an der Implementierung 

einer Teilmenge von Ada (Ada-0) gearbeitet.Der entstehende 
Ada-O Compiler ist als Ausgangspunkt für einen in Ada program- 
mierten Übersetzer der vollständigen Sprache geplant. 

Dieser Ansatz soll es ermöglichen, zusammen mit der Entwick- 
lung und Testung der Übersetzungsalgorithmen auch Programnier- 
erfahrungen in Ada zu sammeln. 


Im Vortrag wird versucht, anhand von Problemen des Entwurfs 
und der Programmierung des Ada-O Compilere Einblick in den 
"Ada-Stil' zu geben. 
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Hopfer, Reiner 


[4 
High-Level Language (HLL-)-Rechnerverbund 


1. Allgemeines 

Die Entwicklung der Programmierung in Richtung der überwiegenden 
Anwendung von höheren Programmiersprachen erfordert eine zweck- 
entsprechende Strukturierung der Hardware. sowie die ‚Bereitstel- 
lung geeigneter Systemsoftware für Rechner und Rechnerverbund- 
systeme. Das dabei verfolgte Ziel ist zum einen eine höhere 
Leistungsfähigkeit der rechentechnischen Geräte und zum anderen 
die Schaffung von Möglichkeiten für eine effektivere und zu- 
verlässigere 'Softwareentwicklüng. Darüber hinaus macht sich in- 
folge der immer komplexer werdenden Aufgabenstellungen für den 
Nutzer eine Vereinfachung der Programmierung, insbesondere von 
parallelen Prozessen und Echtzeitvorgängen, notwendig. Gegen- 
wärtig zeichnen sich daher im internationalem Maßstab Entwick- 
lungen ab, die eine sogenannte direkte Ausführung von Programmen 
in Hochsprache zum Inhalt haben. Das bisher angewendete Über- 
setzer-Binde-Lade-Prinzip ist nicht mehr notwendig. Rechner, die 
eine derartige Arbeitsweise gestatten, werden als HLL-Rechner 
(High-Level Language-Rechner) bezeichnet /1,2,3/. Der Vorteil 
eines solchen vereinfachten Gebrauchs,von Rechnern wird beson- 
ders wirksam, wenn HLL-Rechner zu HLL-Rechnerverbunäsystemen 
verknüpft werden. 


2. High-Level-Sprachen 

High-Level (HL-)-Sprachen. (high-level" im Sinne hoch oder "weit 
weg" von der Binärderstellung herkömmlicher Maschinensprachen) 
sind höhere Programniersprachen, die die Darstellung von In- 
formationsverarbeitungsprozessen auf einen relativ ‚kohen Ab- 
‚straktionsniveau gestatten und insbesondere solche 'Eigenschaf- 
ten aufweisen, die die maschinelle Interpretation eines ent- 
sprechenden Programmes ermöglichen. Eine allen Ansprüchen ge- 
recht werdende HL-Sprache gibt es z. Z. noch nicht. 
HL-Endsprachen sind für den Nutzer gedacht, während HL-Zwischen- 
sprachen die Funktion einer internen Bezugssprache übernehmen 
(Bild 1). Unter den HL-Endsprachen haben neben den "normalen" 


EL-Zwischensprachen 
Algorithnische HL-Prozeß- HL-Fach- 
HL»-Sprachen sprachsn sprachen 


Bild 1: Klassifizierung der HL-Sprochen 


(elgorithmischen) HL-Sprachen insbesondere HL-Proseßoprachen 
eine größere Bedeutung. Hier sind nlmtliche für einen Echtzeit- 
betrieb notwendigen Sprachelemente wie für den Parallellauf von 
Echtzeitaufträgen, Ereignissteuerung, Prioritätsscheduling und 
seitliche Synchronisation zwischen den Systemaktionen und dem 
technäschen Prozeß in der Sprache enthalten. 


3. HLi-Rechner 

ELL-Rechner sind Hard- und/oder Softwaresysteme, die in HL- 
Sprachen formulierte Anwenderprogramne direkt ausführen können, 
In ollgeneinen ist bei einer solchen Betriebsweise kein für den 
Hutzor zugängliches Betriebssyatenm im herkömmlichen Sinne vor=- 
handen. Außerdem sind keine Übersetzungen durchzuführen. Alle 
Schritte der Progremmierung und die für die Steuerung des In- 
Zormationsverarbeitungsprozesses notwendigen Aktionen werden 

' mit den Mitteln der HL-Sprache beschrieben. Eventuell fehlerhafte 
Sprachkonstruktionen oder Laufzeitfehler werden während der Aus- 
führung eines Programmes erkannt und angezeigt. Im Bild 2 sind 
die möglichen Prinzipien der Sprachverarbeitung dargestellt, wo- 
‘bei im klasnischen Fall die Zwischensprache auch entfellen kann. 
Dio direkte Interpretation einer HL-Endsprache entspricht der 
tatsächlichen HLL-Verarbeitung. Demgegenüber muß bei der Inter- 
pretation einer HL-Zwischensprache ein Übersetzungsvorgeng vor- 
gelagert werden. Der gesante Prozeß wird auch Quasi-HLL-Verar- 
beitung bezeichnet. Die Vorteile einer HLL-Verarbeitung dbe- 
otehen in einem effektiveren Abarbeiten der Programme, dem 
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Klassischer Quasi-HLI- HLI-Rechner 
Rechner Rechner 
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"Bild 2: Vererbeitungsprinzipien bei Digitelrechnern 


Wegfall der sonat Üblichen maschinellen Zwischenstationen eines 
Programmen, der leichteren Fehlerermittlung und -korrektur sowie 
einer höheren Softwarezuverlässigkeit. Als Nachteil ist zu werten, 
daß HLL-Systeme im allgemeinen nur für eine Programniersprache 
optimal arbeiten und der Einsatz bereits vorhandener Software 

aus anderen Quellen begrenzt ist. 


4. HLL-Rechnerverbund 

4.1. Physische Grundstrukturen 

.Komploxe HLL-Systeme werden durch Verbund von HLL-Prosessoren 
.dzw. HLL-Rechnern (Verarbeitungseinheiten) auf dem Hiveau einer 
HL-Sprache aufgebaut. Sämtliche auszutauschenden Informationen 
werden mit den Mitteln der HL-Sprache dargestellt. Bein Vor- 
dund von HLL-Vererbeitungseinheiten haben drei Grundstrukturen 
besondere Bedeutung (Bild 3): | 

- Hulti-HLL-Prozessorsysatene 

- Hulti-HLL-Rechnersystenme 

- HLL-Rechner-Hetzverbund. 

Während die ersten zwei Systemklassen insbesondere für homogene 
Systemkomponenten und nur für kleinere Entfernungen. (lokaler 
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HLL- ' HLL- HLL- 
Prozessor Prozessor Prozessor 


a) 
PS |Ein-/Aus- \ 
(HLL- gabe 
Programm) 
HLL- HLL- 
Prozessor Prozessor 

b) 
globale .Ein-/Aüs-: 
Ressourcen gabe - 

ec) 


IKommunikationssysten Be 


Bild 3: ee: bei HLL-Rechnerverbundsystemen 

(a) Multi-HLL-Prozessorsystem, b) Multi-HLL-Rechner- . 
system, c) HLL=-Rechner-Netzverbund; PS - Programmspei- 
‚cher, E/A.- Ein- und Ausgabesysten) 
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Bereich) Anwendung finden, ist letztere mehr fiir die Verkopplung 
von hetrogenen HLL-Komponenten sowie für kleine und große Ent- 
fernungen geeignet. Beim HLL-Rechner-Netzverbund ist das Kommu- 
nikationssystem die physische Basis aller notwefdigen Informa- 
tionsübertragungen zwischen den einzelnen HLL-Komponenten. Eine 
geeignete Lösung stellt das für herkömmliche Rechnernetze viel- 
fach verwendete ISO-Referezmodell mit Schichtenstruktur der, 
wobei der HLL-Verbund der obersten Anwendungsschicht entspricht 
/4/. Die physischen Strukturen von HLL-Rechnerverbunäsystemen 
sind jedoch für den Nutzer nicht primär von Interesse, sondern 
mehr die darauf abzubildenden ‘logischen Strukturen. 


4.2. Logische Strukturen 

Bei HLL-Verbundsystemen kann der Nutzer entsprechend seiner zu 
lösenden Aufgabenstellungen logische Strukturen von Verarbei- 
tungseinheiten und von zu bearbeitenden Dateneinheiten bzw. 
-beständen aufbauen. Besondere praktische Bedeutung in der Or- 
ganisation der Verarbeitungsprozesse haben Gleichoränungsstruk- 
turen, Unterordnungsstrukturen und hierarchische Strukturen 
(Bild 4). Hinsichtlich der (logischen) Kopplungsart hat men 
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Bild 4: Ausgewählte logische Strukturen bei HLL-Rechnerverbund 
(a) Gleichordnungsstruktur, b) Unterordnungsstruktur, 
c) Hierarchische Struktur; V - HLL-Verarbeitungseinheit) 
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zu unterscheiden: 

- Direktkopplung 
Die Anweisungen werden ausgetauscht und anschließend von der 
empfangenden Verarbeitungseinheit sofort ausgeführt. 

- Indirektkopplung 
Anweisungen und Daten werden übertragen, zu einen Programn- 
modul zusammengestellt und erst denn ausgeführt. 


4.3. Dialogbetrieb, Prozeßhetrieb 

Da im allgemeinen ein HLL-Rechnerverbundsysten für den Nutzer 
kein "sichtbares" Betriebssystem enthält, müssen bei Dialogbe- 
trieb bzw. interaktiven Betriebsweisen die entsprechenden Dialog- 
komponenten im Sprachverarbeitungssystem enthalten sein. In ans- 
loger Weise gilt bei Prozeßbetrieb, daß im Sprachsysten Echt- 
zeitkomponenten enthalten sind, die die Synchronisation und die 
Kommunikation von Programmeinheiten sowie die Ereignissteuerung 
und die Zeitverwaltung Übernehmen. Alle zu realisierenden Aktio- 
nen sind demnach mit den Mitteln der HL-Sprache auf logischen 
Niveau zu beschreiben. Dies vetrifft insbesondere auch Logische 
_Interrupts und logische Unterbrechungsbehandlungsroutinen /5/. 


5. Praktische Realisierung 

Für die Realisierung eines HLL-Rechnerverbundes wird ein hier- 
archisches Rechnersystem mit drei Ebenen vorausgesetzt, was in 
physischer und logischer Struktur übereinstimmt /6/. Die logische 
Verkopplung erfolgt auf dem Niveau einer HL-Enäsprache. Als Aus- 
gengusprache dient die Programmiersprache BASIC, die durch ent- 
sprechende Sprachelemente 'erweitert wird. Eine Echtzeitfähigkeit 
wird durch zusätzliche Sprachelemente auf der untersten Hier- 
archieebene erreicht. 


6. Zusammenfassung 

Im Vortrag werden der Rechnerverbund von mehreren HLL-Rechnern 
auf dem Niveau einer höheren Programmiersprache behandelt, aus- 
gewählte Lösungsmöglichkeiten angegeben sowie deren Vor- und 
Hachteile diskutiert. Es wird gezeigt, welche sprachlichen Wittel 
zur Realisierung eines Informationsaustausches zwischen den ver- 
schiedenen Rechnern notwendig und wie die einzelnen Sprachver- 
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erbeitungssysteme zu koppeln sind. Ein HLL-Rechnerverbund ist 
dann vorteilhaft einzusetzen, wenn dem Nutzer ein "durchsich- 
tiges" verteiltes Rechnersysten zur Verfügung steht, auf dem er 
selbstündig, ohne Inanspruchnahme zusätzlicher Betriebssysten- 
dienste, auf einer relativ "hohen Ebene" seine Aufgabenstellung 
programmieren und die gäobale Gesamtfunktion des verteilten 
Systens überblicken kann. Besonders günstig erweist sich gegen- 
wärtig ein Einsstz bei Verbund von mehreren Einchiprechnern so- 
wie bei einem hierarchischen Verbund von Rechnern sehr unter- 
‚schiedlicher Leistungsfähigkeit. 
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Eutschenreiter, Jörg: Grundlagen und Implementation von 
verbundenen Fachspraohen 


Mit zunehmendem Einsatz der Rechentechnik in verschiedenen 
Fachgebieten erhalten Fachsprachen als effektives Verständigungs- 
mittel mit dem Automaten immer größere Bedeutung. Während mit 
bisherigen Compiler-Generatoren Compiler für algorithmische 
Programmierspraohen vom Spezialisten in re"ativ kurzer Zeit 
hergestellt werden können, verlangt das massenhafte Auftreten 

von Fachspraohen, daß diese bereits vom versierten Programmierer 
implementiert werden können. 

Hit dem hier vorgestellten Forschungsresultat "Verbundene Fach- 
spraohen" und seiner praktischen Umsetzung in Form des Metasystems 
DEPOT2a steht ein solches Werkzeug zur Nutzung zur Verfügung. 

Es 1s% ausgerichtet auf die umfassende Verwirklüchung fachsprach - 
licher Kommunikation (deskriptive und algorithmische Fachsprachen) 
Mit seiner Hilfe wird Software für die Analyse und Verarbeitung 
(z.B. Transformation in Zielsprachen, Interpretation) von Fach- 
sprachen automatisch aus der Sprachbeschreibung mit Hilfe einer 
Metasprache erzeugt; Das Konzept der lokalen Sprachen gestattet 
es, Querverbindungen zwischen Fachsprachen herzustellen, bereits 
implementierte Fachsprachen und deren Teile nechzunutzen für 
andere. Imflementationen sowie eine schrittweise modulare Sıftware 
Entwicklung vorzunehmen. Damit ist das System als Bestandteil 
einer effektiven Software-Teohnologie, die auf Fachsprachen 
aufbaut, einsetzbar. 

Das System DEPOT2a ist sowohl für ESER- als auch SKR-Rechentechnik 
realisiert mit einheitlioher Netasprache ML2a und Steuersprache 
CL2a für das DEPOT-Betriebssystenm, 
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Dr. R. Kosctolowicz 


Erfahrungen bei der Anwendung des Modulkonzeptes_von M-PASCAL 


i. Modulkonzepte in verschiedenen Programmiersprachen 


Der Begriff dee Moduls wird in sehr unterschiedlicher Weise 
verwendet und umfaßt je nach Anwendungsfall ein zusammenhän- 
gendes Programmstück, eine Prozedur, eine Obersetzungseinheit, 
eine Ladeeinheit oder vergleichbare Einheiten. Dadurch kommt 
es häufig zu Mißveretändnissen bei der Benutzung dieses Bo- 
griffes. In diesem Beitrag geht es nicht um eine weitere De- 
finition des Begriffes Modul bzw. modulare Programmierung 
sondern um Moduln im Sinne von MODULA 2 /4/ bzw. ADA. und un 
das Progrannieren mit solchen Moduln. Dabei handelt es sich 
nicht um ein Wortspiel. Moduln in diesem Sinne ermöglichen 
eine exakte Schnittstellenbeschreibung für die Zusammenarbeit 
miteinander, die auch vom Compiler überprüft werden kenn. Es 
ist möglich, abstrakte Datentypen nit Spezifikationsteil (was 
wird gemacht?) und Implementationsteil (mie wird ee reali=- 
siort?) zu entwerfen und exakt abzubilden. Für die gesante 
Strukturierung und den Ablauf von Problemlösungen ergeben 
sich neue Möglichkeiten mit exakteren Kontrollmechanienen, Zu 
den bekennten Strukturierungsnmöglichkeiten in Progrannierspra=- 
chen mittels Prozeduren, strukturierten und elementaren An= 
weisungen kommen weitere wesentliche Formen hinzu. Mit Hilfe 
der Sprachkonstruktionen für Moduln ist ee möglich, abstrakte 
oder reale Datentypen geeignet zu strukturieren und die Ein=- 
heit von Datenobjekten und den zugehörigen Operationen sinn- 
voll auszudrücken, Durch getrennte Formulierung und Überset- 
zung von Definitions- und Implementationsteil auch zu ver- 
schiedenen Zeitpunkten können Entwurfsentscheidungen beeser 
dokumentiert bzw. detaillierte Entscheidungen hinausgeschoben 
werden. Durch die separate Übersetzbarkeit von Moduln verbun= 
den mit einer Kontrolle der exakten Schnittstelleneinhaltung 
stehen wesentlich bessere Hilfsmittel zur Verfügung als exter- 
ne Prozeduren und gemeinsam genutzte globale Bereiche. Eine 
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deutliche Analogie der Modulprinzipien zu Entwurfsmethoden 
und -hilfemitteln, die sich bereits bei der’ Konstruktion von 
Maschinen und Geräten durchgesetzt haben, ist nicht nur Zu- 
fall sondern Absicht. Mit dem immer weiteren Anstieg der Menge 
und der Komplexität der zu entwickelnden Software ist es not- 
‚wendig, solche neuen und. leistungsfähigen Sprachelemente für 
die allgemeine Nutzung bereitzustellen und Erfahrungen bei 
deren Anwendung zu sammeln. 


2. Erfahrungen bei der Progremmierung mit Moduln 


Die bereits genannten Vorteile der Programmierung mit Moduln 
zeigen: aber auch gleichzeitig das Hauptproblem - wie findet 
man eine gute Modulstruktur, die der Aufgabenstellung ent- 
spricht, einen hohen Verständlichkeitsgrad hat und spätere 

ı Modifikationen erleichtert? Es ist immer möglich, euch mit 
gut durchdachten, leistungsfähigen Sprachelementen einer Pro- 
grammiersprache beliebig schlecht strukturierte und schwer 
verständliche Programme zu schreiben. Andererseits eind gut 
strukturierte Programme auch mit den Mitteln der Assembler- 
eprache möglich. Dazu sind ein guter Programnierstil und um- 
fangreiche Erfahrungen des Programnierere notwendig. Die 
Sprachelenmente alleine sind nur ein Hilfsmittel, bestehende 
problemepezifische Zusammenhänge besser auszudrücken. Der 
Progrannierer muß es lernen, mit diesen Hilfsmitteln effektiv 
umzugehen. Dies gilt besonders für die Strukturierungsmög- 
lichkeiten, die deutlich über die Prozedurtechnik hinausgeht, 
Das Prinzip der Lokalität bei Daten und den zu ihnen gehören- 
den Operationen ist wesentlich besser realisierbar. Es bieten 
sich ausreichende Möglichkeiten zum Schutz von Implementa- 
tionabesonderheiten bei Datenstrukturen und Algorithmen (In- 
formation hiding). Durch eine bausteinartige Zerlegung in 
relativ selbständige Teilaufgaben kann die Komplexität der 
Problemlösung vereinfacht werden, wobei das exakte Zusammen- 
spiel durch den Compiler und in der Laufzeit geprüft wird. Es- 
ist möglich, universell nutzbare, problemspezifische Datenty- 
pen zu entwickeln und zur allgemeinen Nutzung bereitzustellen. 
Ein wesentliches Prinzip bleibt auch weiterhin gültig. Eine 
gute Struktur der entstehenden Software kann nicht als Ergeb- 
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nie vieler Modifikationen gefunden werden, sondern ist mög- 
lichst früh zu entwerfen. Dabei ist eine vollständige Un- 
strukturierung einer schlechten Struktur im Endeffekt besser 
und sicherer als mehrere Veränderungen an Teilstrukturen. Die 
Güte der gewählten Strukturierung erweist sich in der. Regel 
erst beim Test und bei nachträglich notwendigen Modifika- 
tionen. Die Erfahrungen der letzten Jahre zeigen aber, daß 
auch die Einführung dieser neuen Sprachelenente in einen gro- 
ßen Nutzerkreis äuf einen deutlichen traditionellen vider- 
stand stoßen wird. Deshalb ist es notwendig, anhand von Bei- 
spielen und ausgewählten Projekten die Leistungsfähigkeit 
dieser Ausdrucksmittel zu dokumentieren. Ihre effektive An- 
wendung erfordert aber ebenso Kreativität und Erfahrungen der 
Programmierer beim Umgang damit. Es muß gich ein klareres 
Denkschema bei der Strukturierung und Manipulation von Daten 
entwickeln. Außerdem zeigt sich, daß die Strukturierung des 
Programmablaufs und der Daten im gegenseitigen Wechselspiel 
vorzunehmen sind, um zu gut strukturierten und zuverlässigen 
Programmen zu kommen. Das Infragestellen der bisherigen Ar- 
 beitsweise bedeutet zwar eine Verunsicherung, ist aber auch 
gleichzeitig eine Quelle für neue Möglichkeiten .und erfordert 
Geduld und Fingerspitzengefühl. Administrative Maßnahmen zur 
schnellen Einführung neuer Sprachkonstruktionen führen selten 
zum Erfolg, sondern verhärten oft bereits vorhandene Vorur- 
teile, 


3. Kriterien für die Strukturierung mit Moduln 

Folgende Kriterien haben sich für die Wahl einer guten und 

verständlichen Struktur in der Literatur /4/ und bei der ei- 

genen Arbeit bewährt: 

-"das Interface zwischen Moduln sollte möglichst einfach sein 
(Anzahl der gemeinsamen Größen und Komplexität der Zusam- 
menhänge) 5 

- kurze Importlisten sind anzustreben, besonders in Dofini- 
tionsmoduln 

- es sollten möglichst keine Variablen exportiert werden. 
Wenn Variable importiert werden, dann sollten sie nur als 
read-only-Variable benutzt werden (entspricht dem Seiten- 
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effekt bei Funktionen und Prozeduren) 
=. lokale Moduln (in Moduln oder in Prozeduren) sollten nur 
in Ausnahmefällen (problenspezifisch) angewendet werden 
= Moduln sollten weitgehend unabhängig von der Programnunge= 
bung entwickelt und getestet werden, in die sie eingebettet 
sind. 


Es sind häufig 3 typische Modularten anzutreffen: 

a) Aktionsemoduln, die im wesentlichen aus Prozeduren bestehen 
_ und meist nur Hilfsgrößen als lokalo Daten haben. Sie wer- 
den z.B. für Konvertierungen zwischen verschiedenen Dar- 
stellungsformen (Liste, Baum, sequentielles File) oder für 

spezielle Algorithmen (Sortieren) benutzt. 

b) Datenobjektmoduln, die einem konkreten Vertreter eines ab- 
strakten Datentyps entsprechen. Es werden nur die Zugriffs- 
operationen nicht aber der interne Datentyp exportiert 
(z.B. Identifierliste, Fileverzeichnis). 

c) Datentypmoduln, von denen mehrere Vertreter erzeugbar sind, 
da sowohl der Datentyp als auch die Zugriffsoperationen 
exportiert werden (z.B. Warteschlange, Keller). 

Bei konsequenter Anwendung der angegebenen Möglichkeiten läßt 

eich z.B. ein Mißbrauch von Kenntnissen über den internen Auf- 

bau von Datenstrukturen (z.B. Listen) verhindern, da der Zu- 
griff nur über die exportierten Prozeduren und Funktionen 

erfolgen kann. Änderungen von Implementationsdetails, wie z.B. 

die Ersetzung eines Array durch eine verkettete Liste sind 

möglich, ohne die Benutzungsstellen außerhalb des Moduls zu 
verändern, Außerdem vereinfacht sich die Lokalisierung von 

Fehlerquellen sowie deren Beseitigung. Durch einen vorgezoge- 

nen Test herausgelöster Moduln läßt sich die Komplexität vie- 

ler Testfälle vereinfachen. Die nach den oben genannten Prin- 
zipien entwickelten Programmen zeigen deutliche strukturelle 

Unterschiede zu herkömmlichen Programmen. 


4. Erfahrungen bei der Arbeit mit M=PASCAL 


Bei der Annendung des Modulkonzeptes in M-PASCAL zeigten sich 

folgende Besonderheiten: 

- Es existeren deutlich weniger Verschachtelungen von Moduln 
oder Prozeduren ineinander. Dafür gibt es mehr gleichbe- 
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rechtigte Moduln, deren Zusammenwirken durch Inport-Export= 
Listen beschrieben wird (ähnlich dem Bausteinprinzip in 
technischen Anlagen). 
= Es gibt keine langen und unübersichtlichen Vereinbarungs- 
teile mehr, da entsprechend dem Lokalitätsprinzip Daten 
und zugehörige Aktionen in Moduln zusammengefaßt werden. 
= Durch die Benutzung von Definitionsmoduln entstehen gleich- 
zeitig wichtige Dokumentationselemente für die Struktur und 
die Schnittstellen untereinander, 
= Definitionsmoduln sind eine wichtige Grundlage für Abstin- 
nungen im Entwicklerkollektiv und trennen wesentliche von 
unwesentlichen Informationen. 
Die von und vermendeten Compiler und Precompiler für M-PASCAL 
verfügen zur Zeit nicht über Möglichkeiten zur separaten Über- 
setzung von Definitions- und Implementationsmoduln. Damit er- 
gaben sich einige technologische Probleme für die Übersetzung 
und den Test, die aber die Möglichkeiten der Anwendung des 
Modulkonzeptes für unser Projekt nicht wesentlich einschränk- 
ten. Umfangreiche Anwendungen von MODULA 2 für verschiedene 
Projekte in unserem Bereich lieferten vergleichbare Aussagen, 


Literatur :. 


/i4/ Bothe, K., Kosciolowicz, R. "M-PASCAL - a language for 
modular PASCAL programming”, Preprint, Humboldt- 
Universität zu Berlin, 1983 


/2/ tHohberg, B. "Abstrakte Datentypen beim Programmentwurf 
am Beispiel eines syntaxorientierten Programmeditore 
für PASCAL”, WBZ TU Dresden, Haft 61, 1982 


/3/ Kosctolowicz, R. "Konzeption eines Programmierlabors 
zur Unterstützung des modularen Programmentwurfs 
mit PASCAL”, BIT'82 Tagungsmaterialien 


/4/ Wirth, N. "Programming in MODULA 2”, Springer Verlag 
Berlin Heidelberg New York, 1982 
Dr. ren nat. R. Kosciolowicz 
Humboldt-Universität zu Berlin 
Sektion Mathematik 
1086 Berlin, Postfach 1297 


5-39 
Hager, Klaus 


Anwendungen des Faohsprachensystems DEPOT 


N 


1. Das Fachsprachensysten DEPOT 

Die Bedeutung von Fuchsprachen, d.h. stark problemabhlingigen 
Programmiersprachen, als wesentlicher Bestandteil einer effek- 
tiven Software-Technologie ist in den letzten Jahren allgemein 
anerkannt worden, Diesem Trend tragen die Entwioklungen an den 
Varianten des Fachsprachensystems DEPOT (siehe /1/,/3/,/5/,/7/) 
Rechnung, 

Die Hauptaufgabe dieses Programmsystens, das mit einer Neta- 
sprache zur Beschreibung der Syntax und der Verarbeitung von 
Sprachen ausgestattet ist, besteht in der automatischen Gense- 
rierung von Faohsprachenübersetzern aus der metasprachlichen 
Beschreibung. Das System DEPOT2a eignet sich auch zur interpre- 
tativen Verarbeitung von Faohsprachen sowie zur Implementierung 
von Fachspraohenverbunden. Weiterhin wurde es bereits erfolg- 
reich für Übertragungen von Programmen einer höheren Progran- 
niersprache von einer Rechenanlage auf eine andere (Übersetzung 
zwischen verschiedenen höheren Programmiersprachen oder ver- 
sohledenen implementierungsabhängigen Varianten ein und dersel- 
den Sprache) sowie zur Formelmanipulation angewandt, . 
Un einen Kindruck von der Mannigfaltigkeit der mit DEPOT reali- 
sierbaren Faohspraohen zu vermitteln, sollen im folgenden. drei 
der in jüngster Zeit entwickelten und implementierten Fach- 
sprachen vorgestellt werden, und zwar M-FORTRAN, GEKO und 
DAPRUR. Daneben gab und gibt es eine Reihe weiterer bedeutender 
Anwendungen wie,die Realisierung der Sprache PILOT zur Manipu- 
lation von Datenbanken oder Sprachen zur Robotersteuerung. 


2. B-FORTRAH zur sprachlichen Stützung des Matrixmoduls 
ES1055/HAUO 


Der Hatrixmodul ES1055/MANO wurde als Zusatzeinheit der Reohen-. 
anlage EC1055 zur beschleunigten Abarbeitung von Vektoropera- 
tionen geschaffen. Damit steigt durch Ausnutzung von Parallel- 
arbeit die Abarbeitungsgeschwindigkeit von Vektoroperationen 
wesentlich gegenliber der komponentenweisen (skalaren) Verarbei- 
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tung durch die Zentraleinheit, Da die Programmierung dieses 
Prozessors auf sehr niedrigem Maschinensprachenniveau erfolgt, 
ist es als Voraussetzung für eine breite Rutzung des Natrixmo- 
duls unbedingt erforderlich, eine sprachliche Bean suf 
höhersprachlichem Niveau einzuführen, 
Die an der Sektion Mathematik der TU Dresden entwickelte Sprache 
M-FORTRAN (siehe /5/) stellt eine echte Erweiterung von FORTRAN 
/ESER dar, in der Algorithmen Über ein- und zweidimensionalen > 
Feldern problemangepaßt, d.h. unter anderem mittels Operationen 
mit ganzen Feldern entsprechend dem in der Mathematik üblichen 
Matrigenkalkül, formuliert werden können. Der mit DEPOT2a 
realisierte Übersetzer ist in der Lage, Teiloperationen Über 
diesen Feldern dem schnelleren Matrizmodul zu Übertragen. 


Im einzelnen sind in M-FORTRAN folgende Feldoperationen 
vorhanden: 


3.m.A Multiplikation des Feldes A mit skalarem 
Faktor s 

AB, A=.B elementweise Addition, Subtraktion, Hultipli- 
kation der Felder A und B 

AnuB Skalarprodukt bzw. Matrizenprodukt 

A(a:b) Teilfeldbildung, & unterer, b oberer Index 


Az,k), Ali,z) Teilfeldbildung, k-te Spalte bzw. i-to Zeile 
der Hatrix A. | 


Axzsrk .‚Potenzieren einer Hatrix A 
AxuT Transponleren 
Axn-1 Invertieren 


Beliebige Klammerungen in den Feldausdrücken sind möglich, 
Felder können auf Gleichheit geprüft werden, E bezeichnet die 
Einheitsmatrix, 0 die Nullmatrix. Überlagerte Teilfslder können 
mit neuen Variablennamen bezeichnet werden. Weiltsrhin unter- 
stützt die Kennzeichnung einer Matrix bei der Deklaration als 
symmetrische, antisymmetrische, obere oder untere Dreiscksmatriz 
oder Diagonalmatrix ihr Abspeichern in reduzierter Form. Eine 
Reihe von Standardfunktionen, z.B. zur Determinantenberechnung, 
"Rangbestimmung oder Ermittlung extremaler Elemente ergäinzen 

die Sprache, il 
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Der mit DEPOT2a erzeugte Vorübersetzer Übersetzt M-FORTRAN-Pro- 
sramme in FORTRAN/ESER-Programme, in denen zur Ausführung der 
Feldoperationen Assembler-Unterprogramne des zugehörigen Lauf- 
zeitsystens aufgerufen werden. Von diesen Laufzeitroutinen wird 
zur Verarbeitung von Feldern bzw, Teilfeldern der Matrimmodul 
ES1055/MAMO benutzt, 


3. Die 3D-Modellierungssprache GEKO 


GEKO (Geometrisohe Konstruktion) ist eine Fachsprache zum gleich- 
namigen 3D-Modelllerungssystem (siehe /6/). Sie ermöglicht die 
Beschreibung geometrischer Objekte und Operationen. 


Zu den Objekten gehören elementare konvexe und zusammengesetzte. 
Die elementaren Objekte werden mit Definitionsanweisungen fol- 
sender Gestalt beschrieben: DEP a =sxz; 
Hiermit wird die Variable a als geometrisches Objekt vom Typ 8 
definiert, das den durch x beschriebenen Wert erhält, 
Für s kann eines der Schlüsselworte 

PUNKT, GERADE, EBENE, 

STRZ (Streckenzug), 

RECHTECK, DREIECK, KREIS, 

QUADER, PYRAMIDE, PSTUMPF, ZYLINDER, KEGEL, KSTUHPF, 

POLY (konvexe Hülle) stehen, 
Die Besohreibung z besteht z.B. aus 

drei Komponenten (PUNKT), 

einer Punktliste (STRZ), 

Länge, Breite und Höhe (QUADER) oder 

einer Objektliste (POLY). 


Die wesentlichen Operationen mit geometrischen Objekten sind 
Verknüpfungen und Transformationen, 
Verknüpfungen; 
A+B Vereinigung (bzw. Zusammensetzen) der Objekte A und B, 
A-B Differenz, als Resultat entsteht der Teil des Objektes 
&, der nicht in B enthalten ist, 
AsB Durchschnitt von A und B. 


'Beispielmı VOP E = A-Ba(C+D); 


Transformationen: SnE 


VERSCH E VEKTOR PF; 
Verschieben des Objektes E um den Vektor F. 


DREH E GERADE G WINKEL 1; 
Drehen des Objektes E an der Achse G um den Winkel #. 


Weiterhin können Objekte kopiert, gestrichen und elementare in 
zusammengesetzten ersetzt werden. 


Konstruierte geometrische Objekte lassen sich in 3D-Form (alle 
internen Daten) ein- und ausgeben, was zur Arbeit mit Modell- 
katalogen oder zum Anschluß anderer Systeme, z.B. zu statischen 
Berechnungen, genutzt werden kann. Weiterhin ist die Ein- und 
Ausgabe in 2D-Fornm (projeziert) zur bildlichen Darstellung ndög- 
lich, Hierzu können Projektionsart ausgewählt sowie Angaben Über 
die Darstellung verdeokter Kanten und Mantellinien angefügt 
werden. 

Die Fachsprache wird ergänzt durch Rechenoperationen mit ganzen 
und reellen Zahlen, einfache Elemente der Vektorrechnung, beding- 
te Anweisungen und Laufanweisungen sowie Unterprogrammtechnik. 

In einer Systembibliothek wird eine Reihe von Standardunterpro- 
grammen bereitgestellt. 

Da GEKO geometrisch allgemein gehalten und mathematisch gut abge- 
sichert ist, bringt ihr Einsatz in verschiedenen CAD-Systemen 
Gewinn, z.B. im Maschinenbau oder Bauwesen. 


Neben einem Interpreter für Dialogbetrieb wurde mit Hilfe von 
DEPOT2a ein Vorübersetzer realisiert, der GEKO-Programme in 
FORTRAN Übersetzt. 

Eine GEKO-Zylinderdefinition einschließlich ihrer Übersetzung 
kann z.B. mit folgender ML2a-Prozedur beschrieben werden: 


ZYL: <DEF> NAME <=) CZYLINDER 11 
(RADIUS> EXPR[1] <HOEHE> EXPR[2] 
-> NEXT RECORD KSTEU=504> 
NEXT RECORD <IPARA(1)=? NAUE_ 
NEXT.RECORD (RPARA(1)=> EXPR_[i] 
NEXT RECORD (RPARA(2)=) EXPR_[2] 
ON ERROR( PRINT('DEF Z=ZYLINDER RADIUS R HOERE H') 
ERR } a 
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Von dieser Prozedur werden die ML2a-Prozeduren NAME (Variablen- 


name), EXPR (arithmetischer Ausdruck) und ERR (Fehlerstabill- 
sierung) aufgerufen sowie Mit NAME_ und EXPR_ die durch diese 
Prozeduren erzeugten Zieltexte weiterverarbeitet, 

Der erzeugte FORTRAN-Text besteht aus einer Reihe von Belegungen 
globaler Parameterfelder, die dann vom Laufzeitsystem bei Abar- 
beitung der Aktion abgefragt werden, 


4, Datenprüfen mit DAPRUE 

Überall, wo große Datenmengen anfallen, muß man mit dem Problem 
der Fehler bei der Datenerfassung fertigwerden. Üblicherweise 
versucht man, durch ein vorgeschaltetes Datenpriüfen einen mög- 
liohst großen Prozentsatz dieser Fehler vor der eigentlichen 
Verarbeitung zu finden, Auch für das Datenprüfen ist die Ver- 
wendung einer geeigneten Fachsprache erheblich effektiver als 
etwa das Programmieren der entsprechenden Prüfprogramme in PL/I 
oder gar Assemblersprache, Auch Entscheidungstabellentechniken 
sind noch zu allgemein und wenig angepaßt. 

Hit DAPRUR (siehe /2/) können Daten, die eine feste Record- , 
struktur haden, genrüft werden, Auch das Einteilen einer zu prü- 
fenden Datenmenge in Gruppen, wobei jede Gruppe eine andere 
Struktur aufweist, ist möglich. Für die Prüfungen sind logische 
Ausdriicke, Vergleiohsrelationen und die Mengen-Element-Relation 
zugelassen, Die einzelnen Felder der Records können wahlweise 
als ganze Zahlen oder Zeichenketten interpretiert werden. 


Anhand eines Beispieles soll das Arbeiten mit DAPRUE erläutert 
werden. Gegeben sei eine Lochkartendatei, deren Sätze folgenden 


Aufbau haben: Merkmal Spalten 


\ k A 1-3 
B 4-5 
c 6-7 


An die Datensätze werden folgende Prüfbedingungen gestellt: 
1. A ist eine Zahl aus dem Intervall [101, 175]. 

2. B ist ein Element der Menge [01, 02, O4, 07, 09, 11}. 
3. C ist ein Element der Menge f03, 17, 24, 31]. 

4. Wenn gilt Be[01,02,03}, dann soll gelten Cef03,24} . 
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Diese Prüfungen in ihren gegenseitigen Abhängigkeiten lassen 
sich sehr gut in einem Graphen mit folgenden Kanten und Knoten 


darstellen: 
.} Prüfbedingung [Fehlerreaktion|. 


Voraussetzung 


Prüfungsname 


Für das Beispiel ergibt sich der Graph (in diesem Fall ein Baum): 


> 0el[03, 24) 
p1 "pa 


ce103, 17 
SETT 
Er) 


Das Erstellen eines solohen Graphen gehört zur Technologie, die 
mit DAPRUE mitgeliefert wird, Ein DAPRUE-Programm stellt einen 
derartigen Graphen in linearisierter Form dar, 
Zunächst werden nach dem Schlüsselwort STRUCT die Felder des 
Reoords Bezeiohnet und mit Längen versehen. Dann wird hinter 
SCHEMA die Startprüfung, hier P6, notiert, Anschließend werden 
sämtliohe Prüfungen in beliebiger Reihenfolge aufgeschrieben, 
Eine Prüfung hat die Gestalt: 
prilfungsname: ASSUME voraussetzung CHECK prüfbedingung 

g ERROR fehlerreaktion ; 
Eine Fehlerreaktion Besteht aus einer Nummer, für die im an- 
sohließenden DEKO-Teil eine Pehlernachricht angegeben wird, 
und aus den Bezeichnungen der falschen Positionen, 
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DAPRUE-Programm zum obigen Beispiel: 


PROG BEISPIEL 
STRUCT A(3),B(2),C(2),X(73); 
SCHEUA P6: ASSUME P2&P5; 
P1: CHECK ZAHL(A) ERROR 1,A; 
P2: ASSUME PI CHECK Ay=101 & A<=175 ERROR 2,4; 
P3: CHECK B<:[01,02,03,04,07,09,11)] ERROR 3,B; 
PA: CHECK C<:[03,17,24,31] ERROR 4,05 
P5: ASSUME P3&P4 CHECK B<:[01,02,03] & c<: [03,24] 
I1(B<:[01,02,03])) ERROR 5,B,C; 
DEKO 1, *'unzulaessiges alphazeichen'; 
2, "Zelsch: A nicht im intervall [101,175]; 
3, "falsch: B laut nomenklatur’; 
4, *'2alsch: C laut nomenklatur'; 
5, 'folgebeziehung verletzt: B und C'; 
END; 


DAPRUE wurde am Rechenzentrum der AP# entwickelt, mit DEPOT 
realisiert, d.h. ein Vorlibersetzer in PL/I hergestellt, und seit 
mehreren Jahren mit Erfolg angewendet. Damit gelang es, den Pro- 
Jektierungsaufwand für die Realisierung von Datenprüfaufgaben 
.auf weniger als ein Viertel des bis dahin UÜblichen Aufwandes 

zu senken. 
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RAEX I __- Vorstufe eines Expertensystens für Kleinrechner 


Bei der Entwicklung von RAEX I wurde von folgenden Ideen aus- 
gegangen: 


- Bei der Speicherung von Wissen ist es notwendig, Strukturen 
und Prozesse bzw. Arbeitsprozesse abzubilden, 


- Wissen kann in verschiedenen Komplexitäts- oder Verallgemeine- 
rungsniveaus gespeichert werden. 


- Objektiv und subjektiv ist ein Prozeß eine Zustendsfolge. 


‘= Bei der Repräsentation der Zustandsfolge im Gedächtnis 
existiert ein Zustand in seiner verbalen Beschreibung, und 
ihm sind seine Voraussetzungen und Folgen, die Möglichkeiten, 
ihn durch Aktionen zu verändern, und Zielzustände zugeordnet. 


- Bei notwendiger differenzierterer Nutzung des Gedächtnis- 
besitzes realisiert das Gehirn eine aifferenziertere Abbil- 
dung der Realität über die Eigenschaften der Zustände, 


- Eigenschaften existieren im Gedächtnis in ihrer verbalen 
Beschreibung in Verbindung mit einer Quantität, 


- Der Vergleich zwischen zwei Zuständen im Gehirn kann nur bei 
formaler Gleichheit der Abbildungen der Zustände realisiert 
werden. 
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Die zwei folgenden Abbildungen widerspiegeln den beschriebenen 
Ansatz: 


Aktionen 


Zustand 1 Zustand 2 


Abb. 1 Modell für die Abbildung eines 
Arbeitsprozesses im Gedächtnis 


a8 


Gewicht Abstand Gewicht Abstand 


Abb, 2 Vergleich zweler Zustände 
im Gedächtnis 


In den Abbildungen nicht enthalten ist die Tatsache, daß ein 
Problem erkennt und in dem existierenden Wissens- bzws ‚BrZabrungs> 
schatz zugeordnet werden muß, 
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Im Gehirn wird diese Zuordnung Über von den Psychologen so- 
benannte semantische Netze realisiert. 


Wir haben jetzt einen Ansatz formıliert und wollen Ihnen nun mit 
der Erläuterung der Möglichkeiten von RAEX 1 zeigen, wie der 
Ansatz umgesetzt wurde. 


Sie haben vor sich einen leeren Wissensspeicher, den Sie völlig 
frei mit Begriffen füllen können, die Sie nur von Ihren ganz 
persönlichen Bedarf notwendiger Informationen abgeleitet haben, 
und die für Sie eine zentrale Bedeutung besitzen, 

Stellen wir uns die Situation nach diesem ersten Schritt bei 
einem Abteilungsleiter software-entwicklung vor. 


ARBEITSGRUNDLAGE ARBEITSZIELE BASISPROZESSE 
PROGR. SPRACHEN LITERATUR ARBEITSPARTNER 
EXPERTENSYSTEME KNOWLEDGE ING KADER 

GESETZL. GRUNDL. PROJEKTE 


Der zweite Schritt besteht in der Untergliederung jedes einzel- 
nen Begriffs in Unterbegriffe. Im ersten Schritt haben wir eine 
erste Ebene gefüllt, und wir ordnen im zweiten Schritt jedem 
Begriff der ersten Ebene Begriffe der zweiten Ebene zu. Das ge- 
schieht so, daß wir uns einen Begriff der ersten Ebene aus- 
wählen, z. Be * LITERATUR ' und für diesen Begriff die 
zwelte Ebene füllen; wir füllen entweder mit Klassennamen für 
die Literatur oder schon mit Verfassernamen. 


Bei RAEX I können Sie eine Begriffshierarchie bis in die sechste 
Ebene realisieren, Da in diesem Teil des Projekts nur die 
Begriffe behandelt werden, sprechen wir von der Arbeit im 
Begriffsraum. 


Im Begriffsraum können Begriffe gespeichert und gelöscht werden. 
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Das folgende Bild zeigt einen Ausschnitt eines Begriffsraumes, 


so wie er nach einigen Wochen entstanden sein könnte. 


Literatur 
wer , 
Konstruktion software entw. Organisation 
vgl. Übersichten strukt. Progr. Progr. leistungen 
Ber De 
Hansen Hamenn Wössner 


\ 


Abb. 3 _ Beispielausschnitt eines 
Begriffsraumes 


Wir haben uns jetzt einen Überbau, eine Strukturierung bzw. 
Klassifizierung unseres Wissensbesitzes für die Zwecke unserer 
Arbeit geschaffen. Als Beispiel wurde individuelle Struktur- 
information verwendet. Vergessen wir nicht, es gibt auch 
Strukturinformationen, die in der Gesellschaft vereinbart sind, 
und es gibt auch Prozeßinformationen, Für die Erläuterung des 
Prinzips hat diese Unterscheidung keine Bedeutung, wohl aber 
für die Benennung und für das Verständnis des nun folgenden 
Raumes, dem Raum der sachlichen Informationen zum Übergeordne- 
ten Begriff bzw. dem Raum der Zustandsbeschreibungen. 
Dieser Raum kann von jeder Ebene erreicht werden. In ihm sind 
die Definitionen von Zustandsfolgen oder von Strukturelementen 
in 2 x 80 Zeichen gespeichert. Unser Beispiel von Abb. 3 fort- 
führend stellen wir uns hier einen Buchtitel vor: 

Einführung in das Programmieren in LISP 

Verlag Walter de Gruyter, Berlin (West) 1982 


Ein Beispiel für die Speicherung eines Zustandes Ist: 
'Das Galtonbrett steht senkrecht, eine Kugel befindet 


sich im Startloch, ! 
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In einer konkreten Anwendung des Systems sind in diesem Raum 
zum Zustand oder Strukturelement vereinbarte Zusatzinformationen 
speicherbar. Bei der Abbildung von Prozessen kann das z. B. eine 
Aktion sein. Verwendet man das System zur Terminkontrolle, würde 
der Text eine Aufgabe sein, und als feste Zusatzinformation sind 
ze Be Auftraggeber und Endtermin sinnvoll. 
Die Gestaltung dieses Raumes wird am stärksten durch die Wünsche 
und speziellen Forderungen des Nutzers geprägt. Hier beschreibt 
der Anwender in verschiedenen Differenzierungs- bzw. Hierarchie- 
niveaus seine Prozesse oder Strukturelemente so, wie es in der 
Kommunikation üblich ist. Für Prozessinformationen müßte in 
diesem Raum ein Zustandsnetz realisiert sein; die Anwendung von 
RAEX I machte dies nicht erforderlich, hier existieren einfache 
Zustandsketten. 


Sollte diese Beschreibung nicht hinreichend genau oder sollten 
Ergänzungen notwendig sein, kann man diese zum Zustand oder zur 
sachlichen Information im Eigenschaftsraum speichern. In diesem 
‚Raum kann man einen Eigenschaftsnamen und einen 6 x 80 Zeichen 
langen Text zur Beschreibung der Eigenschaft speichern. Dieser 
Reum enthält also eine differenzierte Beschreibung des Zustandes, 
den Versuch der Beschreibung des internen Zustandsabbildes, 

Die interne Repräsentation von Zuständen ist das Fundament für 
Denken und Kommunikation, der Eigenschaftsraum ist das Funda- 
ment für die Anwendung des Systens, 

Hier können Verweise auf Abbildungen in Büchern, Karteien, 
Hinweise zur Realisierung des Zustandes, zu seinen Voraus- 
setzungen und Folgen gespeichert werden. 


Voraussetzung zur Beherrschung dieses Raumes, zur Beherrschung 
dieses Systems, verehrte‘ Damen und Herren, ist die Ordnung 
unseres Wissens, ist die Beherrschung der Arbeitsmittel, ist 
die Überlegenheit des Geistes Über die Basisprozesse, Auch 
deshalb heißt so ein System Expertensystem. Voraussetzung für 
die Anwendung eines Expertensystems ist Klarheit Über den 
abzubildenden Problemraum oder Wissensbereich. 


wir haben das System bis jetzt von der Seite der Eingabe kennen- 
gelernt. Wenden wir uns der Seite der Auswertungen zu, 
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RAEX I wurde als Terminkontrollsystem entwickelt. Das bedeutet, 
der Raum der sachlichen Informationen heißt Aufgabenraum. Das 
bedeutet aber auch einen bemerkenswerten Unterschied für das 
Auswertungsverhalten des Systems. Bei der Terminkontrolle sollen 
in einer wichtigen Auswertungsvariante alle Aufgaben eines vor- 
gegebenen Zeitraumes angezeigt werden - also unabhängig vom 
direkt übergeordneten oder von den übergeordneten Begriffen. 
Dagegen soll bei Prozeß- und Strukturinformation nur die Kammer 
des Raumes der Zustandsbeschreibungen bzw. der sachlichen Infor- 
mationen angezeigt werden, die dem Übergeordneten Begriff direkt 
zugeordnet ist, 


Wenn ich bei Terminkontrolle die Tagesaufgaben zu sehen wünsche, 
möchte ich natürlich alle der Forderung entsprechenden Aufgaben 
sehen, ohne erst die Begriffe atklappern zu müssen. Wenn ich das 
System als Wissensspeicher nutze, interessiert mich niemals das 
ganze gespeicherte Wissen, sondern Wissen eines konkreten 
Bereiches auf einem konkreten Differenzierungsniveau, 

‚Dieser Unterschied differenziert Systeme zur Wissensaufbewahrung 
und -vermittlung und Systeme für die Leitung von Entwicklungs- 
und Forschungsprozessen. 


RAEX I wurde für die Leitung eines Entwicklungsprozesses ge- 
schaffen. Die Unterstützung bei der Realisierung der Akten- 
ordnung war eine Zusatzforderung. Ein Abbild der Aktenordnung 
ist aber Wissen, die Abbildung in die Speicherstruktur Wissens- 
speicherung. Das heißt, beide sich grundsätzlich unterscheidenden 
Auswertungen mußten dem Anwender zur Verfügung gestellt werden. 
Für die Auswahl von Aufgaben existieren in RAEX I folgende 
Möglichkeiten: 


L| 


zu einem Begriff einer Ebene 
ohne Begriffszuordnung 


zu einem Auftragnehmer 
zu allen Auftragnehmern 
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die erfüllten Aufgaben 


die nicht erfüllten bzw, 
verlängerten Aufgaben 


Aufgaben in einem Zeitraum 
Tagesaufgaben 


Aufgaben nach ihrer Wichtigkeit sortiert 


Die beschriebenen Eingabe- und Ausgabemöglichkeiten lassen dem 
Nutzer des Systems einen großen Spielraum; er kann das System 
den Notwendigkeiten seiner Arbeit und seinen Bedürfnissen an- 
passen. Diese Variabilität ist aber auch eine Gefahr. Die Gefahr 
heißt Unordnung in der Vorstellung Über die Basisprozesse. Das 
System setzt Ordnung im Problemraum und Klarheit in der Vor- 
stellung des Nutzers voraus. Diese Voraussetzung ist eine 
Forderung für viele komplexe Arbeitsprozesse und erhält durch 
dieses Projekt einen objektiven Maßstab, an dem sich der Nutzer 
messen kenn. 


wir haben bisher den theoretischen Ansatz und den Kern der 
Realisierung erläutert. Im weiteren soll klar werden, wie sich 
RAEX I in das Leitungssystem einordnet und welcher Nutzerkreis 
möglich ist. 

Wenn men das System am Bildschirm aufruft, erscheint die 
Ausschrift: IHRE PERSONALNUMMER, BITTE: 


Sie geben Ihre Personalnummer ein, und es wird geprüft, ob die 
Nummer in der Datei der zugelassenen Nutzer enthalten ist. Wenn 
sie enthalten ist, erscheint die Ausschrift: DAS PASSWORT, BITTE: 
Das Passwort wird ebenfalls auf Zulässigkeit geprüft. Ist es 
unzulässig, wird das Programm beendet, 


Das Passwort trennt die Informationsbestände für verschiedene 
Nutzer oder Informationsbestände eines Nutzers. Der zweite Fall 
ist sinnvoll, wenn sich eine Person mit sehr unterschiedlichen 
Arbeitsgebieten beschäftigt. 

Beliebig viele Nutzer können also mit ihrem eigenen oder bzw. 


und mit einem gemeinschaftlichen Datenbestand arbeiten. 
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Hat das System das Passwort akzeptiert, erscheint eine Funktions- 
auswahl: 


BEGRIFFSRAUM 1 
SCHLUESSEL 2 
POST 3 ö 
ENDE p 


Wählt man die 1, so kann man mit dem System als Terminkontroll- 
system arbeiten. Man kann verschiedene Begriffs- und Aufgaben- 
bereiche auswählen, Begriffe speichern und löschen, Aufgaben 
‚speichern, modifizieren - z. B, Terminverlängerungen oder 
Erfüllungsmeldungen eingeben -, löschen. Und man kann Ergänzungen 
zu den Aufgaben speichern oder sich anzeigen lassen, 


Eine wichtige Rolle bei der Terminkontrolle spielen die Arbeits- 
pläne. Da die Aufgaben gespeichert sind, liegt es nahe, sich die 
Arbeitspläne von RAEX I drucken zu lassen. Auf dem so erzeugten 
Arbeitsplen stehen die Aufgaben, die Endtermine, die Quelle der 
Aufgabe, das Kennzeichen für den Bearbeitungsstand und eine 
Schlüsselnumer für die Aufgabe. Der Arbeitsplan ist nach Auf- 
tragnehmer sortiert. Will der Nutzer nur eine spezielle Aufgabe 
sehen, erhält er mit der Wahl der Funktion 'SCHLUESSEL 2! die 
Möglichkeit, die Schlüsselnummer einzugeben und erreicht damit, 
daß das System die gewählte Aufgabe anzeigt. 

wählt man die Funktion 'POST 3', kann man-eine Nachricht bzw. 
Aufgabe oder Anfrage an ein anderes Bildschirmgerät senden oder 
Nachrichten von anderen Bildschirmgeräten empfangen. 


Damit ist das System zu einem einfechen Kommunikationsmittel 
geworden. Es spart Papier und Zeit und vermindert die Rolle 
subjektiver Fehler bei der Informationsübermittlung. 

Die Daten, die auf diese Weise ausgetauscht werden, können noch 
nicht einfach im eigenen Begriffsraum zugeordnet werden. Ob das 
notwendig ist, wird die Erfahrung zeigen. Bis jetzt bleiben die 
Daten auf dem Postamt’ und können dort separat behandelt werden, 
Ein besonderer Service besteht in der Behandlung von periodisch 
wiederkehrenden Terminen. Diese müssen nur an Beginn der Arbeit 
mit dem System eingegeben werden, 
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Anhand einer angegebenen Zeitspanne erzeugt das System später die 
Termine für Leitungs-, Dienst- und Arbeitsberatungen selbst. 


Wir haben jetzt das System RAEX I in seinen wesentlichen Eigen- 
schaften beschrieben. Wir haben gesehen, daß es in der Lage ist, 
Wissen unterschiedlicher Art zu speichern und in einer Ordnung zu 
verwalten. Stellen wir uns nun die Frage, unter welchen Beding- 
ungen sich so ein System als nützlich erweist. Unter welchen Be- 
dingungen wird so ein System effektiv? 


So ein System ist nützlich, wenn 

- die Basisprozesse eine hohe Komplexität aufweisen, 

- Einzelpersonen diese Komplexität beherrschen müßten, 
um ihre Arbeit in hoher Qualität und Quantität zu 
realisieren, 

- relativ lange Einarbeitungszeiten in Arbeitsgebiete 
existieren, 

- einige Aufgaben selten vorkommen, aber ein komplexes 
Herangehen an die Lösung erfordern, 

- sich ein komplexer Informationsraum häufig verändert 
und mehrere Personen mit dem aktuellen Stend arbeiten 
müssen, die Zeit für Informationsaustausch aber fehlt, 

- es auf hohe Genauigkeit in der Informationsübermittlung 
ankommt (die Genauigkeit muß in der Formulierung durch 
den Eingebenden erzeugt werden - das System stimuliert 
die redundanzarme Eingabe), 


wir wollen jetzt an zwei einfachen Beispielen die Arbeit mit 
RAEX I demonstrieren. In Beispiel 1 beschreiben wir einen 
Handelsprozeß und speichern für ein Arbeitsgebiet die gesetz- 
lichen Grundlagen, Unter dem Begriff 'HANDEL! seien gespeichert 
'TEXPORT', *IMPORT!, 'BINNEN!, Und unter 'EXPORT'!' seien gespei- 
chert 'ANGEBOTSPROZESS', "'VERTRAGSPROZESS', "REALISIERUNG', 
Im Begriffsraum sei die Begriffsfolge 
‘HANDEL ' 'EXPORT' 'VERTRAGSPROZESS! 
ausgewählt worden, die Ebene 4 sei leer, 
Wir speichern zu Ebene 4 den neuen Begriff 

"GESETZLICHE GRUNDLAGEN! 
und gehen in den Aufgabenraum Über, 
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Der Bildschirm zeigt jetzt das Bild: 


AUFGABENRAUM 
HANDEL EXPORT VERTRAGSPROZESS 
REALISIERUNG. 


ı AE 


Mit den Buchstaben AE melden wir eine Eingabe an, und wir können 
an der mit '-' bezeichneten Stelle eine gesetzliche Grundlage. 
eingeben, 2. B. 

'VTG 1197! 


'BINISTERRAT' '12.11.1984' 
Dieses Beispiel zeigt ein Problem, Für jeden Begriff der zweiten 
Ebene gibt es gesetzliche Grundlagen, d. h., der Begriff muß 
mehrfach gespeichert werden. In einer Systementwicklung bietet 
sich für dieses Problem eine Rationalisierung an. 


Das zweite Beispiel soll unseren Lebensprozeß beschreiben. Wir 


fragen das System nach den Möglichkeiten, unsere Freizeit zu ge- 
stalten,. Im Begriffsraum sei gespeichert: 


ME a ra 


SPORT “ BILDHAUEREI | FREUNDE 
DEE az an Su 


PLATTE | RADIO ZA KLASSIK JAZZ DYLEN 


TONBAND KONZERT OPERETTE ROCK JANACEK 
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Im Aufgabenraum können hier die Möglichkeiten der Freitzeit- 
gestaltung zu den konkreten Begriffen gespeichert sein. 


An diesem Beispiel werden zwei weitere Probleme deutlich, 

In Ebene 4 sehen wir, daß Begriffe der Tonerzeugung nach Ihrer 
physikalischen Herkunft differenziert neben Begriffen der Genre- 
zugehörigkeit von Musikstücken und Begriffen, welche Komponisten 
und Sänger bezeichnen, existieren. Für einen Wissensspeicher für 
den individuellen Gebrauch ist das sicher kein Problem. In 
Wissensspeichern für die Gemeinschaft muß jedoch sorgfältig er- 
wogen werden, in welchen Fällen man besser eine weitere Zwischen- 
ebene schafft, 

Das zweite Problem existiert ebenfalls für eine gemeinschaftliche 
Anwendung des Systems. Wenn eine Stelle die Konzertpläne eingeben 
würde und diese für alle Nutzer zur Verfügung ständen, wäre doch 
eln gutes Stück gesellschaftlichen Arbeitsaufwandes gespart, und 
die Systemnutzer würden beim aktuellen Bedürfnis nach einem 
DYLEN-Konzert angezeigt bekommen, daß, wo und wann so ein Konzert 
stattfindet. 

Die Auswertung Veranstaltungen eines Zeitabschnitts muß selbst- 
verständlich auch zur Verfügung stehen. 


Nun irt folgende Frage interessant: Wie kann das System zu einem 
Expertensystem werden? 

Zunächst ist die Antwort einfach: indem ein Experte für Leitungs- 
t&ätigkeit oder eine Gruppe von Experten für den geforderten 
Arbeitsbereich einen Anfangsdatenbestand schafft, d. h. das 
Fachwissen und das Leitungswissen speichert, die Beratungs- 
perioden und Standardabläufe festlegt. Wer sind denn aber die 
Experten für ein Wissensgeblet, und wo sind die Grenzen für ein 
Wissensgebiet? Welche Wissensgebiete enthalten aggregiertes 
Wissen oder Wissen Über analoge bzw. vergleichbare Prozesse, 
welche Regeln gibt es zur Verallgemeinerung von Wissen, ist 
Verallgemeinerung Überhaupt sinnvoll? Das sind Fragen, auf die 
die Praxis eine Antwort geben muß, 

Wer sich für so ein System entscheidet, sollte sich wenigstens 
drei Fragen gestellt und entsprechend drei klare Antworten formı- 
liert haben, 


‘ 
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Die Fragen sind: 


- Für welches Wissensgebiet soll das System genutzt werden? 


- Wie soll sich das System in die bereits existierende 
Organisation einfügen? 


- Wodurch ergibt sich der zu erwartende Nutzen? 


Verantwortungspewußte Antworten sind der Garant für die 
Erfüllung der Erwartungen. 


Werfen wir nun noch einen kurzen Blick in die Zukunft, 


Für das System lassen sich zwei wesentliche Entwicklungs- 
richtungen erkennen. Die erste Richtung enthält die Analogien 
zu den CAD-systemen, z, B,. ein System zur Unterstützung der 
software-entwicklung oder ein System zur Unterstützung der 
Erfindungstätigkeit. Bei diesen Anwendungsfällen liegt das 
Problem eher bei der Schaffung geeigneter Wissensfonds - sie 
sind also prinzipiell realisierbar, . 

Die zweite Richtung zielt auf die Wissensverarbeitung. Für diese 
Richtung ist erstens noch Grundlagenforschung der Psychologie 
über die Dialektik und Effektivität von anschaulichem und be- 
grifflichem Denken bei Problemlösungsprozessen notwendig, 
zweitens scheint es notwendig, daß die hardware-hersteller 
begriffsverarbeitende Bauelemente produzieren bzw. solche Bau- 
elemente produzieren, die die Begriffsverarbeitung optimal 
unterstützen, 


Diese Forderung sel kurz erläuterts 


Jeder Zustend läßt sich in der Form von Abb. 2 darstellen, 
Im Computer ist die Darstellung j 


ZN: E1Q1M1 E2Q242 .... ENOQNMN mit 
ZN = Zustandsnanme 
f E = Eigenschaftsneme 
Q =. Qantität 
M z Maßeinheitname möglich 
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Für den Computer sind Namen gleich Adressen; an diesen Adressen 
sind Zeichenketten gespeichert. Der Mensch versteht diese Dar- 
stellung in ihrer externen Form auch: 


'Raumklima: Zugluft 2 m/s 
Temperatur 20° C 


Die Reaktion auf Zustände hängt von den Zielstellungen der 
Menschen ab; diese Ziele sind aber auch Zustände und durch 
Aktionen zu erreichen. Die Beschreibung der Aktionen ist 
speicherber. 


Diese Darstellung erfordert für ihre Verarbeitung außerhalb des 
Gehirns geringen Aufwand und ist für alle Vorgänge des Denkens 
im rationalen Bereich anwendbar. Sie bietet die Möglichkeit, 
einen Algorithmus für die Abbildung von-Denken im Computer zu 
schaffen. 


Notwendig für Wissensverarbeitung scheint weiterhin ein Bild- 
schirm mit den Ausmaßen des Gesichtsfeldes des Menschen und 
ein frei gestaltbarer Zeichenvorrat., 


Das Wesentliche an der Wissensverarbeitung, die direkte Unter- 
stützung des menschlichen Denkens, läßt sich auch mit heute 
und hier existierender Technik realisieren. Beide Wege, die 
Entwicklung neuer hardware und die Entwicklung und Testung 
neuer software, müssen parallel beschritten werden. 
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Merken Sie sich bitte von diesem Vortrag das Folgende: 


In der DDR existiert mindestens ein System, daß sich als 
Expertensystem eignet. Es ist auf vorhandener Technik imple- 
mentierbar. Es ist ein Basissystem und an verschiedene Nutzer- 
forderungen gut anpaßbar. 


Expertensysteme können die Effektivität, die Qualität und die 
Sicherheit von Entwicklüngsarbeit wesentlich erhöhen. Bei dem 
immer größer werdenden Komplexitätsgrad der Entwicklungen gibt 
.es zu Expertensystemen keine Alternativen. Expertensysteme 
sind also keine Wunschvorstellungen von träumenden software- 
entwicklern, sondern entscheiden Über die Mark, die morgen 
uns oder anderen gehören wird. 


Ich hoffe, alle, die es angeht, haben verstanden. 
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Dr,=Ing. Alfred Schilling 


Es soll Aufbau und Wirkungsweise des "Compiler 
Sytems" (CWS) im Überbliok dargestellt werden. 
PASCAL programmierte System ist am ORZ der KMU 


Writing: 
Dieses in 
Leipzig im- 


plementiert und wird zur Zeit umfassend erprobt. 
Das Ergebnis der Anwendung dieses Systems ist ein vollstän- 
diger Compiler in PASCAL, wobei der Ausgangspunkt eine LL(1)- 


Grammatik der Quellsprache in einer speziellen 
form ist, 


"Dr.-Ing. A. Schilling 
Kerl-Marx-Universität Leipzig, ORZ 
7010 Leipzig 

Karl-Marx-Platz 


Darstellungs- 
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Staudte, Rainer 


PROLOG-Interpreter fuer Nikroreohner 


Einige Vorteile und Probleme der Anwendung von PROLOG auf 
Mikrorechnern werden diskutiert und erste Ergebnisse 
der Arbeit mit einen experimentellen PROLOG-Systenm 
vorgestellt. 


1. Bessere Anwendungsbedingungen der logisohen Programmierung 


Die unmittelbar auf der Basis mathematischer Logik beruhenden 
Programmiersprachen, unter ihnen PROLOG, haben sioh in den 
letzten Jahren rasoh verbreitet. Ein nioht unwesentlicoher Grund 
fuer diese Popularitaet sind Implementationen auf relativ 
kostenguenstigen Mikroreohnern, die eine dezentrale Nutzung 
dieser Sprachen gestatten und ihre Anwendung nicht mehr auf 
wenige leistungsfaehige Rechenzentren beschraenken. 

Als Beispiel dieses Trends sei Mioro-PROLOG von Logio 
Programming Assoolates genannt das etwa 240 Resolutionen je 
Sekunde fuer Z80-Prozessoren Ch MHz) erreicht. Nioro-PROLOG 
existiert neben dieser a in CP/M auoh fuer 8088/86 An 
MSDOS und £Zuer weitere Mikrorechner u. a. auoh in UNIX /1,2/. 


2. Spezielle Probleme der Implementation von PROLOG 


PROLOG-Implementationen fuer NMikroreohner erfordern die Loesung 
spezieller Aufgaben, die sich aus Hardware und Software dieser 
Klasse von Rechnern ableiten. Binerseits ist das die relativ 
geringe Operationsgeschwindigkeit der Prozessoren. Da PROLOG 
vorwiegend interaktiv genutzt wird, ist diese Restriktion nicht 
nachteilig, wenn die Antwortzeit mit der mensohlichen 
Reaktionszeit vergleichbar bleibt. 

Problematiscoher ist die Frage der Verwaltung des meist sehr 
besohraenkten Hauptspeiohers. "Der gesamte Komfort der Spraohe, 
darunter ihre Vorzuege wie Strukturen, Listen, Matching und 
Baoktraoking, werden teuer bezahlt, wenn man die dafuer 
notwendigen Hauptspeioheranforderungen in Betraoht zieht" /3/. 
Prinzipielle Wege zur Loesung dieser Aufgabe sind dynamische 
Speicherverwaltung mit virtueller Adressierung /4/ oder modulare 
Organisation des PROLOG-Programms und Veberlagerung. 

Aush wenn die Implementationsfragen vor dem Anwender verborgen 
bleiben, so darf man bei der Beurteilung eines PROLOG-Systens 
ihre Existenz nioht vergessen. 


3. Ein portabler PROLOG-Interpreter 


Ungeachtet der zuletzt genannten speziellen Probleme einer 
PROLOG-Anwendung fuer praxisrelevante Aufgaben sind Mikroreohner 
ein geeignetes Hilfsmittel zur Untersuchung typischer Fragen der 
logisohen Programmierung. In diesem Fall ist die Einbettung des 
Interpreters in eine problemorientierte Programmiersprache mit 
Entwioklungssystem sinnvoll. 
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Neben bekannten Implementationen in PASCAL und PLZ fanden die 
Arbeiten zur Entwicklung eines. abgeruesteten PROLOG-Interpreters 
in verschiedenen BASIC-Versionen fuer die Nikroreohner PC 8001 
und HO-20 bisher wenig Beaohtung /5,6/. Beweis fuer die hohe 
Portabilitaet diese Interpreters ist seine Implementation und 
Weiterentwicklung im SCPX /7/. Sie ist besonders geeignet fuer 
Neulinge in PROLOG. 

Eine weitere Moegliohkeit, einem noch breiteren Nutzerkreis zur 
logisohen Programmierung Zugang zu verschaffen, ist die 
Umsetzung dieser Version auf Lerncomputer. Hier machen sioh 
natuerlioh geringer Hauptspeioherplatz und fehlender BASIC- 
Compiler zur Zeit noch sehr nachteilig bemerkbar. 


4, Zum Test eines PROLOG-Systens 


Wesentliche Merkmale zur Characterisierung eines PROLOG-Systens 
sind Operationsgeschwindigkeit und maximale Anzahl gleichzeitig 
aktiver Klauseln. Nachfolgende Beispiele gehoeren zu den 
Erfahrungen, die der Autor bei seiner ersten Bekanntschaft mit 
einem PROLOG-System und dessen Testung sammelte /8/. 

Eine grobe Aussage zum Zeitverhalten kann man bei der 
klassischen Aufgabe zur Positionierung von acht Damen auf einen 
Sohachbrett erlangen, indem man die Aufgabe auf n Damen. auf 
einem n x n - Brett erweitert. Verzichtet man auf konstruktive 
Vefahren und wendet die Methode der vollstaendigen 
Durohmusterung an, so erweist sich hier die kombinatorische 
Vielfalt als hinreichend. Bereits ab n=6 ist ein merkliches 
Anwachsen notwendiger Backtrackingoperationen zu verzeichnen. 
Verfeinerte - Testverfahren unterscheiden zwischen 
Baoktraokgeschwindigkeit und Realisierung reiner logischer 
Interferenzen. Ein (nicht ganz typisches) PROLOG-Programn fuer 
letzteres ist in folgendem Fragment eines Ablaufprotokolls von 
/U enthalten: 


ist 
1 fac(0,1). 
:2 fao(A,B) :- sub(A,1,0),fao(C,D),mıl(D,A,B). 
PROLOG OK 
?-fac (2,Ergebnis). 
- 2- 2- 1-0 


+++ one answer is ++ 
2 


PROLOG OK . 

Die Ziffern nach dem Aufruf zur Berechnung von 21 protokollieren 
aktivierte Klauseln. Am Zeilenende steht o fuer einen 
erfolgreichen Beweis, x kennzeichnet ein Backtracking. 

Folgendes Programm deckt leicht evtl. Limitierungen bei der 
Anzahl gleichzeitig aktiver Klauseln: 


: load 5-64 


file name ?FIBONA 
PROLOG OK ) 
: list 
1 u: 1), 
2 fibo(1,1). 
3 fibo(A, ‚B) = sub(A,1,C),sub(C,1 

i fibo(0,E),Fibo(D, ee F,B). 
PROLOG OK 


?-fibo(4,Resultat). 
- > 3 3 2- i- 2- 3 2- 1-0 
+++ one answer is +++ 


5 
PROLOG OK 
3 fibo(A,B) :- sub(A,1,C),sub(C, ‚ie ); 
fibo(h, F),add(F,P ‚G),addlG, D,H),sub(H,1,B). 
PROLOG OK 


?-fibo(4,Resultat). 
- 3 3- 1-0 


++r one answer is +++ 


5 
PROLOG 0K 
Berechnet wird jeweils das fuenfte Element der FIBONACCI-Folge. 
Dabei erfolgt im ersten Aufruf die Berechnung streng nach 
Definition. Nach entsprechender Korrektur der Klausel 
dokumentiert der zweite Aufruf die reduzierte Beweislaenge. 
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EXPERT PROBLEM SOLVING USING IF-THEN RULES 


If-then systens are the problen-solving systems based on mat- 
ching simple rules to given problems. The purpose of this paper is 
to summarize what if-then systems are and to show how they can be 
implemented in LispKit Lisp 1 oe, which is a dialect of Lisp 
language. The expert knowledge can be represented as collections 
of if-then rules, which have the following forn: 

IF <trigger fact 1 is true> 

<trigger fact 2 is true> 


( 


THEN <conclusion fact 1 is tmue> 
<conclusion fact 2 is true> 
Systems based on if-then rules can do convincing medical dia- 
gnosis, natural language understanding, planning and problem solv- 
ing, sequence prediction, and 80 on. 
There are many ways to represent rules. The following one ena- 
bles easy access to the rule parts: 
(RULE <nane> 
(IF <trigger fact 1> 
<trigger fact n> ) 
(THEN <conclusion fact 1> 
<conclusion fact n> )) 
The facts can be represented as lists of atons 
The problem solver can do forward and backward chaining. A pro- 
blem solver is doing forward chaining if it starts with a collection 
of facts and tries all available rules over and over, adding new fa- 
cts as it goes, until no rule applies. A problem solver is doing ba- 
ckward chaining if it starts with an unsubstantiated hypothesis and 
tries to prove it. The strategy involves finding rules that demonst- 
rate the hypothesis and then verifying the facts that enable the mı- 
le to work. 
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Dr. Klaus Wiederänders 
"PASCAL für Mikrorechner" 


An der Sektion Mathematik der Humboldt-Universität 
werden seit mehreren Jahren Compiler für PASCAL-Sprachen 
auf kleinen Mikrorechnern entwickelt, Als Zielreahner 
Zungieren K1520-Rechner (MRES, BC5120, OEM-Rechner) mit 
den Betriebssystemen MEOS, SCP,.W/OS, UDOS eto. und in 
Zukunft deren 16-Bit Nachfolger. Quellsprachen sind PASCAL/H, 
Conourrent Pascal, Modula-2 und. PARCAL/M2, für die 'an der 
Humboldt-Universität Mikrorechnercompiler vorliegen. 

Vorgestellt wird im Detail die Vertragsentwioklung für 
des Kombinat Robotron zur Installation von PASCAI/M2 für 
BC5120 unter SCP, 


Dr. K. Wiederänders 
Humboldt-"niversität Berlin 
Sektion Mathematik 
Bereich Informationsverarbeitung 
1086 Berlin 

PSF 1297 
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On-line-Nutzung der Externspeicher des K 1600 für mehrere 
Büroconputer A 5120 


1, Vorbemerkungen 
Im rechentechnischen Labor der Sektion Mathematik der Hum- 


boldt-Universität zu Berlin werden mehrere Bürocomputer 

A 5120 sowohl zur Forschung als auch zur Ausbildung einer 
großen Zahl von Studenten eingesetzt. Eines der Hauptproble- 
me bei diesem Einsatzprofil ist die Speicherung von Daten, 
d.h. Quelltexten, ausführbaren Programmsystemen und nutzer- 
spezifischen Daten sowohl für die tägliche Arbeit der Wissen- 
schaftler und Studenten als auch für längere Zeit zur Archi- 
vierung der gewonnenen Forschungsergebnisse (Datenumfang 
einer Compilerentwicklung PASCAL z.B. über 5 M Byte). Die 
Bürocomputer A 5120 verfügen standardmäßig neben den Minidis- 
kettenlaufwerken K 5600 mit maximal 200 K Byte Kapazität 
(Formatierung 1024 Byte pro Sektor) Über keine externen Spei- 
chermedien. Kassettenmagnetbandgeräte und 1/2"-Magnetbandge- 
räte sind serienmäßig nicht verfügbar. Zur Archivierung einer 
Compilerentwicklung werden z.B. ca, 25 Minidisketten benötigt. 
Um trotzdem die oben genannten Aufgaben langfristig lösen zu 
können, ist es notwendig, weitere externe Speichermöglich- 
keiten für die Blirocomputer mutzbar zu machen, da die notwen- 
dige Zahl von Minidisketten, jährlich zusätzlich mehrere hun- 
dert Stück, nicht zur Verfügung stehen. Eine Lösungenöglich- 
keit für uns bietet sich in der on-line-Nutzung der Extern- 
speicher, Kassettenspeicher CH 5400 und Magnetbandgeräte 

CM 5300 des Rechners K 1600 an. Serienmäßig stehen für eine 
derartige Verbindung zwischen Bürocomputer A 5120 und K 1600 
die Schnittstellen IFSS und V.24 mit einer maximalen Daten- 
transferrate von 9,6. K Bit/s d.h. ca. 1 K Byte/s zur Verfü- 
gung. Dies ist sehr langsam, wenn man berlicksichtigt, daß . 
mit einem Minidiskettenlaufwerk Datentransferraten bis zu 

10 K Byte/s praktisch erreichbar sind. Außerdem ntißte von 
Seiten des K 1600 jeder Bürocomputer Über einen gesonderten 
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Kanal einer Anschlußsteuereinheit bedient werden, was die 
Zahl der anschließbaren Bürocomputer stark verringern wür- 
de. Ein Multiplexer K 8523 für den K 1600 wlirde das An- 
schlußproblem zwar lösen, aber die Datenübertragungsrate 
wäre auch nicht höher. Deshalb wird nachfolgend beschrie- 
bene Iösung realisiert, 


2. Technische Beschreibung 
Die technische Basis für die Kopplung des Rechners K 1600 


mit mehreren Bürocomputern A 5120 besteht aus einer opto- 
elektronischen Kopplung der Bürocomputer und eines OEN- 
Rechners K 1520 untereinander und einer Kopplung des Rech- 
ners K 1600 und des OEM-Rechners auf der Grundlage einer 
SIF 1000 Schnittstelle mittels Anschlußsteuereinheiten ADA, 
Die topologische Struktur dieses lokalen Netzes ist ein 
Ring, der in Abbildung 1 zu sehen ist, 


——— SIF 1000 Schnittstelle 


. % 
: 2 > KR -Knotenrechner 
[KR | BC -Bürocomputer 
BC | IWI-Lichtwellenleiter 


Abbildung 1: Struktur der Rechnerkopplung K 1600-Bürocomputer 
A 5120 


Die optoelektronische Kopplung, die von der Sektion Elek- 
tronik der Humboldt-Universität zu Berlin entwickelt wurde, 
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arbeitet mit einer Datenübertragungßrate von 500 K Bit/s, 
d.h. ca. 60 K Byte/s. Die SIF 1000 Schnittstelle ermög- 
licht eine maximale Datenübertragungsrate von 20 K Byte/s. 
Demit ist zwischen den Rechnern K 1600 und A 5120 eine 
höhere Datenlibertragungsrate möglich, als zwischen dem Pro- 
zessor des Bürocomputers A 5120 und einem angeschlossenen 
Minidiskettenlaufwerk. Beim Zugriff zu den externen Spei- 
cherm des Rechners K 1600 werden also ähnliche Datenüber- 
tragungsraten wie beim lokalen Zugriff zu Minidisketten- 
laufwerken erreicht, 
Die von der Sektion Elektronik entwickelte optoelektro- 
nische Kopplung beruht auf einer optischen Informations- 
Übertragung mittels Lichtwellenleiter. Dazu wird in jedem 
Bürocomputer und in dem OEM-Rechner zusätzlich ein Knoten- 
rechner bestehend aus zwei Leiterkarten, Medienkarte und 
Buscontroler, integriert. Diese Leiterkarten haben ein An- 
schlußbild entsprechend des K 1520-Buses, so daß weitere Ver- 
änderungen en den Büroconputern nicht notwendug sind. Die 
freien Steckplätze sind in der Regel vorhanden. Die Medien- 
karte realisiert die Umforming der optischen in elektrische 
Signale und umgekehrt, Gleichzeitig realisiert sie die Re- 
peaterfunktion für das optische Medium falls die im Ring 
transportierten Daten nicht für den konkreten Knotenrechner 
sind oder falls der Bürocomputer nicht eingeschaltet ist 
(separate Stromversorgung der Repeaterfunktion). Der Buscon- 
troler mit U880 Prozessor steuert den Transport der Daten 
zwischen Medienkerte und einem im Buscontroler lokalisierten 
RAM-Bereich, der als Dual-Port-Memory ausgebildet ist. Der 
Datenaustausch zwischen Knotenrechner und Bürocomputer wird 
mit Hilfe dieses Dual-Port-Memory realisiert, in dem dieser. 
Speicherbereich zeitweise in den Adreßraum des Bürocomputers 
eingeblendet wird, wenn der Bürocomputer Daten empfangen bzw. 
senden will. Das Ein- und Ausblenden des Speicherbereichs 
wird durch den Bürocomputer gesteuert. Der Speicherbereich 
kann bis 8 K Byte eroß sein. Der Knotenrechner meldet an- 
kommende Datenblöcke durch Interruptsignale, Die Schnitt- 
stelle Knotenrechner-Bürocomputer entspricht bezüglich dem 
OSI-Referenze-Modell der Schicht 3 -Netzwerkschicht- mit 
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nEnde zu Ende" Kontrolle. Der Zugriff zum optischen Medium 
erfolgt durch den Knotenrechner mit dem Verfahren CSMA/CD. 
Die Abbildung 2 gibt einen Überblick über die Struktur der 
Kopplung von Bürocomputer und Knotenrechner, 


E -optischer Mm- 
pfänger 
S -optischer Sender 
R -Repeator 
= B -Buscontroler 


M ’-Medienkarte 
K 1520-BUS ppy-Dual-Port-Memory 


2 


Abbildung 2: Struktur des Bürocomputers mit Knotenrechner 

1 
Bei der Kopplung K 1600-0EM K 1520 wird jeweils eine An- 
schlußsteuereinheit ADA mit Schnittstelle SIF 1000 bemutzt, 
wobei die. Anschlußsteuereinheit des OEM-Rechners leicht mo- 
difiziert wurde, da diese Schnittstelle eigentlich nicht für 
Rechner-Rechner-Kopplung konzipiert ist. Die genaue Kopplung 
der beiden Anschlußsteuereinheiten ist.in Abbildung 3 darge- 
stellt, 


3. Struktur und Funktion der Koppelsoftware 


Bei der Konzeption der Koppelsoftware wurden folgende Ge- 

sichtepunkte berlicksichtigt: 

1. Der Austausch von Datenpaketen zwischen beliebigen Rech- 
nern des Ringes soll möglich sein, d.h, jeder Rechner des 
Ringes soll Dienste zur Verfügung stellen können und an- 
dererseits Dienste eines beliebigen. anderen Rechners 
nutzen können, \ 

2. Beim Ausfall eines Rechners soll trotzdem die Funktions- 


fähigkeit aller übrigen Rechner gesichert sein und deren 
Arbeitsfähigkeit nicht weiter durch den ausgefallenen 
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Rechner beeinflußt werden. j 
3. Die Schnittstellen der Koppelsoftware zum jeweiligen Be- 
triebssystem sollen möglichst einfach und übersichtlich 
sein, um eine in Struktur und Funktion gleichartige Kop- 
pelsoftware für alle beteiligten Rechner erstellen könen. 


k 1520 


D-Datenbit 
K-Kommandobit 
S-Statusbit 
E-Eingabekanel 
A-Ausgabekanal 


Abbildung 3: Kopplung der Anschlußsteuereinheiten der Rechner 
K 1600 und K 1520 


Die Koppelsofware besteht aus einer Reihe von konkurierend 
arbeitender Prozesse, Diese Prozesse werden durch einen Kern 
gesteuert. Es gibt vier Systemprozesse (Transmitter, Receiver, 
Name-Server, Connection-Control) und mindestens einen Nutzer- 
prozeß. Die genaue Stellung der Prozesse und ihrer Kommuni- 
kationspartner ist aus Abbildung 4 ersichtlich. 

Die Aufgaben des Kerns bestehen in der Initialisierung des 
Gesamtsystems, der Organisation der parallelen Arbeit der 
einzelnen Prozesse und der Prozeßkommunikation. Dazu werden 
vom Kern folgende Prozeduren zur Verfügung gestellt: 
CreatePort -Eröffnen eines Kommunikationspunktes 
ClosePort -Schließen eines Kommunikationspunktes 
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CreatePacket -Reservieren eines Speicherbareiches für ein 
Datenpaket 
ClosePacket "Rückgabe eines Speicherbereiches für ein Da- 
tenpaket an den Kern 


SendMsg =-Senden eines Datenpaketes an einen Port (lo- 
kal) 
Waltisg Warten auf ein Datenpaket mit Zeitbegrenzung 


CreateProcess -Definieren eines Prozesses mit einer bestimm- 
ten Priorität 

WeitInterrupt -Warten auf. eine Unterbrechung von einem Ge- 
rät 

Init “Starten des Gesamtsystenms 


I/0-Driver 
4 ev u 


or 
-. R 
Transmitter | Receiver | 
4 & 


9 ——— 


N er - —d 
9. 


Connection-Control 


-E 


= = ..)Betriebseystenrufe 
—d Prozeßkommnikation 
=. -D Informationsfluß bei Tabellenzugriff 


Abbildung At Prozeßstruktur der Koppelsoftware 


Der I/O-Driver ist Bestandteil des jeweiligen Betriebsystems 
und wird mit den normalen Betriebssystemrufen durch den Trans- 
mitter bzw. Receiver aktiviert, . 

Der Receiver-Prozeß empfängt alle ankommenden Datenpakete und 
sendet sie dann mittels des Kern-Rufes SendMsg an den eigent- 
lichen Empfängerport, der im Datenpaket spezifigiert ist. Der 
Receiver-Prozeß hat die höchste Priorität im Gesamtsystem und 
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ist interruptgesteurt (Kern-Ruf: WaltInterrupt). 
Der Transmitter-Prozeß sendet Datenpakete an andere Roch- 
ner. Dazu übergibt er die modifizierten Datenpakete an den 
I/0-Driver, Wenn der I/O-Driver das Absenden des Datenpa- 
ketes bestätigt, wird das Datenpaket an den Absenderpro- 
zeß zurlickgesendet, Der Tranemitter-Prozeß hat die zweit- 
höchste Priorität im Gesamtsystem. 
Der Hame-Server dient im Gesamtsystem zum lokalisieren der 
Komminikationspunkte (Ports) von Diensten. Dazu wird in 
jedem Rechner eine Tabelle geführt, in der enthalten ist wel- 
che Dienste von den Nutzerprozessen des aktuellen Rechners 
den anderen Rechnern angeboten werden. Der Rame-Server gibt 
eine Positiv-Heldung, wenn ein von einem anderen Rechner g0- 
suchter Dienst in dem aktuellen Rechner zur Verfügung ge- 
stellt wird. 
Der Conneotion-Control-Prozeß dient zur Überwachung von durch 
den Nutzerprogeß aufgebauten Verbindungen. Dazu werden vom 
Connectio-Control-Prozeß zeitzyklisch Testpakete en die jewer- 
ligen Connection-Control-Prozesse gesendet, für deren Nutzer- 
prozesse Verbindungen aufgebaut worden sind. Wird das Test- 
paket von dem entsprechenden Oonnection-Control-Prozeß in 
einer bestimmten Zeit bestätigt, so gilt die Verbindung als 
funktionsfähig, anderenfalls wird die. Verbindung als abgebaut 
betrachtet.und der Nutzerprozeß erhält beim nächsten Zugriff 
eine Fehlermeldung, i 
Ein HRutzerprozeß besteht aus zwei Komponenten, erstens den 
Systemroutinen und zweitens den eigentlichen Nutzerroutinen, 
die entweder einen Dienst des Systems anbieten oder einen 
Dienst des Systems nutzen. Abbildung 5 gibt eine Übersicht 
über die Struktur eines Nutzerprozesses. Die Systemroutinen 
des Nutzerprozesses enthalten die für die Kommunikation mit 
den Systemprozessen notwendigen Routinen, 
Die User-Transmitter-Routine dient zum Absenden von Datenpa- 
keten an andere Rechner. Durch die User-Receiver-Routine 
‘wird auf Datenpakete gewartet. Die User-Name-Server-Ro.ıtine 
dient zum Installieren von Diensten und zum lokal!sieren von 
Diensten auf anderen Rechnern. 
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Die User-Connection-Control-Routine dient zum Auf- und Ab- 
bauen von Verbindungen, zum Senden und Empfangen von Daten- 
.paketen Über aktive Verbindungen und zum Testen der Rınk- 
tionsfähilgkeit von Verbindungen, 


User trenemitter routine 
User receiver routine 


User name User connection 
server routine | control routine 


Abbildung 5: Struktur der Nutzersoftware 


An eigentlichen Nutzerprogrammen wurden vorerst nur ein File- 
transportdienst realisiert, der es erlaubt vom Bürocomputer 
gesteurte Dateien im FCS-Format auf dem K 1600 zu lesen und 
zu schreiben. Weitere Dienste sind möglich, so 5.B. Dienste 
zum Drucken von Files für Bürocomputer, die keinen eigenen 
‚Drucker haben, Zugriff zu Dateien euf Minidisketten von! Büro- 
computern durch den K 1600. 
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Zur Leistungsmodellierung von Rechnersystemen 


0, Einführung 
In diesem Beitrag werden die formelmäligen Ergebnisse eines Zweischichten- 


bedienungsmodells für die Modellierung eines Einzelrechners vorgestellt, 
das auch als Grundlage für die Modellierung von Mehrrechnersystemen /9/ go- 
eignet ist. In diesem Modell werden als Haupteinflüsse die Lastverteilun- 
gen Über die geteilt genutzten und festzugeoränsten Ressourcen erfaßt. 
Außerdem können mit diesem Modell solche Einflüsse wie Systemaigenlant 
(overhead) und ZVEı:B/A-Überlappungen berücksichtigt werden. Die Berliok- 
sichtigung der Systemeigenlast wird im Vortrag behandelt. 


Im Beitreg werden Durchsats-, Reaktions- und Auslastungsverhalten als Ein- 
keit betrachtet, was Ale Analyse des Stepel- und Dialogbetriebs erm’g- 
licht. Der letzte Teil des Vortrages beschäftigt sich kurz mit Ergebnis- 
sen der Leistungsmessung, Leistungsmodelllerung und Leistungsverbesse- 
rung. Dabei wird eine kurze Übersicht Über bereitgestellte Programmpake- 
te gegeben. 


1. Allgemeiner Wodellansatz 
Wir betrachten die typische Konfiguration eines Rechnersystens. Es werden 


von uns geteilt genutzte und festzugeordnete Ressourcen des Rechnersy- 
stons unterschieden. Festzugeordnete Ressourcen werden einem Job für die 
gosante Abarbeitungsseit (Verweilzeit: im Progremmbereich) zugeteilt, 
während die geteilt genutzten Ressourcen verschiedenen Jobs zeitlich ver- 
schachtelt im Laufe der Jobabarbeitungszeit zugeteilt werden. 


In unserem Modell betrachten wir als geteilt genutzte Ressourcen, die 
Einkenalressourcen Zentrale Verarbeitungseinheit (ZVE) und Selektorke- 
näle (SKT,...SK(n-1) und die Unendlichkanalressource (Infinite server) 
(Byte-)Multiplexkanal (HK). Die geteilt genutzten Ressourcen können ent- 
sprechend ihrer funktionellen Bedeutung auch als aktive Ressourcen be- 
seichnet werden. 


Die festrugeoränseten Ressourcen sind in unserem Modell alles Kehrkanal- 
ressourcen und ihrer funktionellen Bedeutung entsprechend passive: Res- 
sourcen. Als festzugeoränete Ressourcen werden in das Modell aufgenommen: 
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die Gesamtheit der Programmbereiche (PB) mit der Zehl m der Programnbe- 
reiche als Kanalsahl, der Hauptspeicher (HS) mit der Hauptspeicherkapazi- 
tat 2, als Kanalzahl, die Gesamtheit der Magnetplattengeräte (KPG) mit 
der Zahl m_ der MPG als Kanalzahl, die Gesantheit der Hagnetbandgeräto 
(MG) mit der Zahl 2, der EBG als Kanalzehl und die Gesamtheit der Druk- 
ker (PD) mit dor Zahl m, der PD als Kanalzabl. 


Für die analytische Hodellierung von Rochnersystemen mit dem Ziel einer 
Leistungsbewertung werden weltweit Eedienungsmodelle, meist Badienungs- 
netze, genutst. Ohne hier auf die Einzelheiten der Bedienungstheorie ein- 
gugehen, kann man für eine Rechnerkonfiguration bei Berloksichtigung der 
oben. angeführten Ressourcen, die Qrobstruktur des Rechnermodells als 
Zweischichtenmodell entsprechend Abb. 1 angeben. In diesen Zweischichten- 
nodell ist su. beachten, daß in der Hodellschich? der geteilt genutzten 
Ressourcen hochfrequsnte Erozesse mit der EAufigkeit des B/A-Zugriffo und 
in der Sobicht der festzrugeorädnsten Hessourcen niederfrequente Prozesse 
mit der Häufigkeit. der Jobaktivierung ablaufen, Die Wachselwirkung er- 
folgt mit der Frequenz der langsamen Erozesse der Schicht der Lestzugeord- 
neten Ressourcen. 


Neben der Rechnerkonfiguration besitzt im Bedienungsmodell der Rechnerin- 
setallation der Arkeitslaststrom eine wesentliche Bedeutung. Ein Haß für 
den Umfang des Arbeitslaststroms ist der Verkehrswert 9 des Gesantsy- 
stems, für den gilt 


„A! 
5- 4; () 
[| 
mit der Ankunftsstromintensität A und der BedienungsintensitKt jE der 
Jobs. Hierbei gilt. 
‘ _ 


mit der mittleren Summenbedienungszeit z, eines Job. 


Außerdem sind die Lastverteilungen Über die geteilt genutzten und Über 
die festzugeordneten Ressourcen als Parameter des Arbeitslaststromes be- 
deutsam. Die Lastverteilung Über die geteilt genutzten Ressourcen ergibt 


sich durch die Beschäftigungskoeffizienten z (in0,1,.00,n}, wobei der 
Index O dem Prozessor, die Indizes 1,...,n-T den entsprechenden Se- 


lektorkanälen und der Index n dem Multiplexkanal entsprechen. Dabei 


gilt 
& =g % (i= 0,4, ın) 6) 
n 
> x= A (4) 
i=0 


att Si als Vorkehrswert der geteilt genutsten Roszsurce Frmer 1 . 


Für die Lastverteilung auf dis Lestzugeoräneten Rossourcen werden die Br 
darfskoeffizrionten y nit 


Ye Nm, (5) 


eingsführt, Dabei ist mn dor mittlere Kanalzahlbedarf eines Job der 
festsugeoränsten Ressourco 1 und a die verfügbare Kanalsalil der Kes- 
source 1, nit 1£FR, wobei FR die Henge der feotzugeorädnsten Ressourcen 


ru «{ep, 25, up, uso, en} (6) 
ist. 


Als Eustanäteile des Leistungsverhaltens einer Rechnerinstsllation werden 
das Durchsatsverlalten, das Resktionsverhalten und das Auslastungsverhal- 
ten betrachtes, Für das Durchsatsverhalten wir@i der Leistungsfektor R, 
für das: Reaktionsverhalten dor Verusilzsitfaktor Fund für das Ausl 
stungsverhalten der Auslastungsgra4 7 des Gosantsystens als Leistungs- 
bewertungsgrößon betrachtet, Diese Leistungsbewertungsgrößen hängen von 
don Konfigewrations- umd Arbeitslestparametern ab, Der Zusammenhang swi- 
schen den Konfigurations- und Arbeitslastparanetern einerseits und den 
Leistungsbeuertungsgrüßen andererseits bildet das Leistungsbewertungsmo- 
dell der Reohnerinstallation, 


2, Tueischichtenbedienungsmodell : 

Unter Kutgung der realen Eigenschaften der Rechnerinstallation, die aus 
Hessungen gewonnen werden, kamn, in Anlehnung an die näherungsweise voll- 
ständige Dekomposition (/1/,/2/), das Gesamtmodell eines Rochnersyatens 
als ein Zueischichtenbeäienungsmodell entwickelt werden (a. Abb. 1). Die 
Hodellschicht der geteilt genutsten HRessoursen kann als erstes, unab- 
hengig von der Hodellschicht der Lestrugeordäneten Ressourcen, berechnet 
werden. Anschließend ist dann die Berechnung der Hodellschicht der fest- 
zugeoräneten Ressourcen, unter Verwendung der Ergebnisse aus der Modell- 
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Ausgangs- 


atron 


Hodellschicht der festzugeoränsten Ressourcen 


Wechselwirkung 


Modellschicht der geteilt genutzten Ressourcen 


äbb. Tr Zweischichtenaufbau des Bedienungsmodeils 
sohioht der geteilt genutzten Ressourcen möglich. 


"In der Abb. 2 wird, eine allgemeine Übersicht über die funktionellen Zusen- 
nenhänge des Zweischichtenbedienungsmodells gegeben. Buide Hodellzchichten 
enthalten wiederum zwei Berechnungsstufen. / 


In der Nodellschicht der geteilt genutzten Ressourcen stellt die erste 
-Eodellstufe eine Schar geschlossener Bedienungsnetze von Centräl-sorrver- 
Typ dar. Aus den Beschäftigungskoeffisienten (Vektor x) und der Zahl der 
geteilt genutzten E/A-Ressourcen n werden Zuischenwerte der Leistungs- 
und Verweilzseitfaktoren R(k), Fk) mit k=1,2,...,m berechnet. 


Auf der Grundlage der Hittelwertanalyse (/3/,/&4/) ergeben sich folgende Be- 
reohnungsforneln 


1+xX en = für 2VE,SK, 


FR(k)= , m 
4 für MK ; 
n v \ 
Fik) = )_ x; Filk) (6) 
(0° ' 
Rik) = k/FIR). (sr 
Hierbei sind j 
Fik) = Telk) /T, t10): 


die Vorweilzeitfaktoren der einzelnen geteilt genutzten Ressourcen. 


Ressourcen 


Hodellschicht. der geteilt | Modellschicht der festzugeordneten 
genutsten Ressourcen 


Abb. 2: Allgemeine Übersicht Über die funktionellen Zusamnen- 
hänge des Zueischichtenbedienungsmodells 
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In der zweiten Berechnungsstufe (ZEG) der Hodellschicht der geteilt genutz- 


ten Ressourcen können verschiedene Einflüsse, wie Überlappte Arbeit inner- 
halb. eines Job und Systemeigenlast: (overhead)) berilcksichtigt. werden. Wir 
beschzrüiinken uns hier auf den Einfluß der Systemeigenlast,. Aus eigenen und 
{renden /5/ Hossungen geht hervor, daß dio Systemeigenlast von der Zahl der 
aktiven Jobs abhängig ist, wobei der linsare Ansatz 


Elk)= 4+%:(k-4) 111) 


für den von k abhängigen Anteil gilt. Dabei ist a der Anstieg der 
Systeneigenlast mit: wachsender Jobzahl und Efk) ist definitionsgemäß des 
Verhältnis von mittlerer Summenbsdienungsseit bei einer bestimmten Aktiv- 
sahl %& zur mittleren Summenbedienungszeit bei ke1. 


In der Modellschicht der fostzugeoräneten Ressourcen heriücksichtigt die 
erste Berechnungsstufe den Einfluß der Bedarfskoeffisienten yı (1ER) 

und der Zahl der maximal möglichen Progreammbereiche m . Als Zwischenstu- 
fo wird eine blockierende Ersatsressourse mit zufälliger Kanalsahl einge- 
führt, wobei die Verteilungsfunktion IT(s) dieser Kanalzahl von y, wd 
m abhängt (s. /6/). Auf dieser Grundlage kann als korrigierter Leistungs- 
faktor 


k-4 ns ( 
R"(k) eo (s)- Rs) +R 7 5) (12) 


aus dem im Modell der geteilt genutzten Ressourcen berechneten Leistungs- 
faktor R (k)) ermittelt werden. 


In der letzten Berechnungsstufe, in der ein N/W/s-Bedienungssystem mit 
virtuellem Bedienungsknoten verwendet wird, kann der Verweilzeitfaktor 
r des (ssamtsystems nach folgenden Formeln rekursiv berechnet werden 


Ar = [S/RUWT- Auı 


Bu= Acıkr Bu 113) 
& = At 
Dm = [A+ 3/Rım] (14) 


und 
2 Bam-4 +Äm Im [m+{8 /r-ım) Dm] 
8 ( 4+ Con + Am‘ Dm) i u e 
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Dabei gelten die Anfangsworte 


A,=d, B,=D, G=D. 116) 


Die Formel (15) ermöglicht die Berechnung des Roaktionsverhaltens dos Gs- 
vanteystens. Das Durchsatsverhalten dos Gosamtsystens ergibt sich mit 


Rt = R'lm). an 
für das Auslastungsverhalten des Gesanteystens gilt 
7° SRr. (16) 


Auf dlosen Toge kann das Leistungsverhalten einer Reohnerinstallation be 
wechnet. worden. 


2, Wesentliche ‚Krgebninne 
In Ergasung su dem im Abschnitt 2 dargestellten Zusischichtenbedienungsmo- 


dell wurden an der TU Dresden in Zusarmenarbeit mit dom DVZ Dresden Neß- 
mittel geschaffen, Außerdem wurden die Modelle und Neßnittel als Grundlage 
Zür die Durohsatzerhöhung bei Reohnerinstallationen der Hassendatenverarbei- 
tung genutzt, Im Vordergrund stand dabei | 


= die optimale Verteilung der Bystemdateien /7/: 
- die Johnetsoptimierung /B/ 
- ein verbessertes BPOOL-Konsept /9/ 

und 
= die optimale Ablaufsteuerung /10/. 


Auf den Ebenen der Leistungsmessung und -auswertung, der Leistungsmodellie- 
zung und der Anwendung £ür die Durchsatserhöhung wurden an der TU Dresden 
eine Anzahl von Programmaketen geschaffen, Bine Übersicht Über ausgewählte 
Programnpakete int in der Abb.: 3 enthalten. Die gekennssichneten Programn- 
pakete wurden an Rechensentren Überfihrt, Dabei befinden sich Teile der Pro- 
eranmpakete (LEIST, EAMON, OPDA SISLAP) in allen 16 DVZ des EDV im produk=- 
tivon Binsats. 
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Rechner- 


BKR ESER 
syaton 


Leistungs- 


modellierung | _STANA | 
Zesnbange“ |_OPDA_| _ mp |]. 
erhöhung 


kbb, 3: Übersicht Uber ausgewählte Programapakete 
der Leistungsnodellierung 


m 
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Burghardt, Frank 


1 


SIMULATION voN KOMMUNIKATIONSPROTOKOLLEN 


4. Einleitung 


Mit der zunehmenden Verbindung von Computer- und 
Kommunikationstechnik in verteilten Rechnersystemen waechst die 
Notwendigkeit, sich waehrend des Entwurfs, Aufbaus und 
Betreibens soloher Systeme mit Fragen der Leistungs- und 
Zuverlaessigkeitsanalyse und des Systemdesigns auseinander- 
zusetzen. Dabei ist die Simulation auf der Grundlage diskreter 
Prozeßmodelle eine wichtige Methode, die Experimente mit sehr 
detaillierten Modellen gestattet. 


Die Prinzipien der Nachrichtenuebertragung zwischen den 
Komponenten des verteilten Systems werden ' durch 
Kommunikationsprotokolle festgelegt. Diese sind Regeln ueber: 

- die Formate und Arten der auszutauschenden Nachrichten, 

- den zeitlichen Ablauf der Nachrichtenuebertragung, 

- die Reaktion auf Fehler und den Wiederanlauf und 

- den Mechanismus des Auf- und Abbaus einer Verbindung. 


Analog den Prinzipien der strukturierten Programmierung hat es 
sich durchgesetzt, den komplexen Vorgang der 
Nachriohtenuebertragung in verschiedene Schichten mit 
funktioneller Arbeitsteilung zu gliedern, wobei jede Schicht zur 
Realisierung ihrer Dienste die .der niederen Schichten in 
Anspruch nehmen kann. Dies fuehrt zu einem hierarchischen 
Sohichtenmodell der Protokolle und erfordert natuerlich genau zu 
fixierende Schnittstellen zwischen den Schichten. /1/ 


Protokolle koennen als Beschreibung der Wechselwirkung 
zweier Prozesse aufgefafßt werden, wobei deren ‚Synchronisation 
durch die Kommunikation mit Hilfe der zu uebertragenden Nach- 
richten erfolgt. Diese paarweise auftretenden Prozesse seien 
Protokolleinheiten genannt. Die Protokolleinheiten reagleren 
beim Empfang einer Nachricht in Abhaengigkeit von ihrem Zustand 
(z.B: Zahl der unquittierten gesendeten Nachrichten, Zahl der 
freien Puffer) i.a. durch Senden einer Nachricht. Daher hat es 
sich bewaehrt, Modelle von Protokolleinheiten als Automaten- 
modelle zu realisieren. 


Gute Unterstuetzung bei der Modellierung solcher Systeme bietet 
die verwendete Programmiersprache SIMULA, die erlaubt, 
- Prozesse und ihre Kommunikation modellzeitlich nachzubilden 
- und mehrere Objekte solcher Prozesse zu generieren. 


2. Simulation von Protokollen k 


Fuer die Modellierung von Protokolleinheiten wurde ein all- 
gemeiner Baustein bereitgestellt, der einige Standardprotokoll- 
operationen sowie die Schnittstellen zu hoeheren und tieferen 
Schichten liefert. Zu den Operationen gehoeren: 


Empfang und Typanalyse von Nach@ithten, 
Pruefen des Zustandes der Protokolleinheit, 
Frasmentieren und Blooken von Nachrichten, 
Yerunlten der internen Zaehler der Protokolleinheit, 
see % mit sogenannten time-outs zur Fehlerreaktion, 
alter Aynamischer Verbindungen (virtuelle Kanaele) und 
ei erieren und Senden von Naohrichten. 


Es gelang, mit diesem Apparat die konkreten Kommunikations- 
protokolle HDLO, X.25 und AP 64 zu modellieren und entspreohend 
Bxzperimente mit verschiedenen Protokollparametern durchzu- 
fZuehren. Duroh ein Traoesystem kann der Ablauf des Nachrichten- 
austausches verfolgt werden. 


3. Simulation von Kommunikationssystemen 


Fuer die Leistungs- und Zuverlaessigkeitsanalyse eines 
Kommunikationssystens ist das Zusammenwirken von Hardware 
Prozessoren, Vebertragungskanaele), Systemsoftware 


einschließlich Kommunikationsprotokolle) und Arbeitslast 
(Nutzerauftraege) zu modellieren./2/ Hinzu kommt die 
Bereuoksichtigung der Topologie eines solchen Systems. Deshalb 
wurden auch dafuer entsprechende Bausteine bereitgestellt./3/ 
Hit der Nutzung eines Dialogkonfigurators hat man die 
Moeglichkeit, 
- beliebige topologische ‚Strukturen von Kommunikationssystemen 
zu generieren, 
- Parameterzuordnungen fuer die Hardware-, Software- und 
Arbeitslastmodelle vorzunehmen und 
- a en von Protokollen verschiedener Schichten 
zu testen. 


Die Statistik des Simulationssystemes ist auf die Betrachtung 
von Durchsatz, Verweilzeiten und Auftreten von 
Vebertragungsfehlern ausgerichtet. 

Bs Ast offensichtlich, daß der Rechenzeit- und Speicherplatz- 
bedarf bei solohen detaillierten Simulationsmodellen erheblich 
ist. In /3/ werden auch Ansaetze zur Veberwindung solcher 
Probleme beschrieben. 
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De. Kunioke, Manfred 
Ein dynamisches Ressouroenüibernaohungasystem 
d trieb e 


"Für die Durchführung eines offektiven Rechenbetrieben ist 
es von großer Wichtigkeit, ntlindig die aktuellen Werte der 
Ressoucenbenutzung zur Verfügung zu haben. Insbesondere 
trit?t dies für kritische Ressourcen, 5. B. ZE-Zeit, Drucker- 
papier zu. Das im Betriebasystem OS/ES beroitgestellte Syaten 
zur Erfassung der Ressouroenbonutzung (BUP) gestattet en 
ewar, sohr umfangroiohe Analysen durchzuführen, diese aind 
allerdings nur Uber größere Zeiträume. (eine Woohe und mehr) 
sinnvoll. ' 

Das von uns entwickelte dynamische. Rossourcenüberwaohungs- 
system wird parallel zum SMF angewandt und hat folgende Auf- 
gaben zu erfüllen: j 

- Überprüfen der Logalität, dor Abreohnungsnumner 

= Saldieren der: Rossourdenbenutzung pro Job 

- Kitteilen des Standes dor Ressouroenbenutzung an den. 

Nutger nach Abarbeitung einos jeden Nutzerjobs 

- Überwachnn der goplanten Limite für dia Ressourcenbe- 

nutzung, 


Das dynamische Resnouroonüberwachungsayntenm ist so gental-. 
tat, daß eo Erweiterungen in Richtung eines abreohnungenum- 
mernberogenen Dateinohutsen zulißt. En kann ?lir die Ressour- 
oonüberwachung vowohi im Stapelbotricb als auch im Teilneh-. 
merbotrieb oingesetzt werden. 

Die programmteohnische Realisierung des Ressouroenüberna- 

ohungsoystems basiert auf Ausgangsroutinen des Syatemeingabe- 

Programms und des Programmlaugorganinatoro sowie einer npori- 
ellon Separatorroutine. Pir die Überwachung: des Druckerpe- 
piervorbrauchs wurde eino Änderung. dor Routine IEP3DY85 
vorgenommen. 

Allo für das Üborwaohungssystem notwendigen Daten (Abrech-. 
nungenummern, Plan- und Istwerte der zu Üiberwaohenden HRes- 
souroen, sowie in zuklnftigon Ausbauntufen Angaben rum Datei- 
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schutz) stehen in der zentralen Nutzerdatei des Überwachungs- 


systems. Diese. befindet sich auf einem residenten Systemplat- 
tenstapel und ist eine Direktzugriffsdatei. Alle Daten, die 
zu einer Abrechnungsnummer gehören, sind zu einer Nutzerein- 
tragung zusammengefaßt und stellen ein Satz fester Länge der 
Nutzerdatei dar. In der Ausbaustufe ohne Dateischutz hat eine 
Nutzereintragung folgendes Format: 


#23 12 f 


NN. - relative Blocknummer der Nutzereintragung 
in der Nutzerdatei 

L - L+i = Anzahl der signifikanten Stellen der 
Abrechnungsnummer 5 

XZXXXXXIX - maximal achtstellige Abrechnungsnumner 

A - Anzeiger, werden benutzt, um erreichte Limite 


bei kritischen Ressourcen zu signalisieren. 
Die Länge einer Hutzereintragung ist abhängig. von der Anzahl 
der im jeweiligen Rechenzentrum zu. überwachenden Ressourcen. 
Für jede Ressource sind in einer Nutzereintragung zwei Worte 
vorgesehen. Es können bis zu acht Ressourcen liberwacht wer- 
den. 

Zur Gewährleistung: eines schnellen Zugriffs zu den Nutzer- 
eintragungen ist eine Steuertabelle vorhanden. Sie hat eben- 
soviele Eintragungen wie die Nutzerdatei. Jede Eintragung 
der Steuertabelle besteht. aus den ersten zwölf Bytes der 
entsprechenden Nutzereintragung. Die 'Steuertabelle ist. Be- 
standteil der Ausgangsroutine IEFUJV des: Systemeingabepro- 
gramms. Anhand der Abrechnungsnumer aus der JOB-Anweisung - 
wird über die relative Blocknummer die absolute Adresse der 
Nutzereintragung CCHHR ermittelt und im gemeinsamen Beröich 
der Ausgangsroutinen allen weiteren Routinen des Ressouroen- 

.Überwachungssystems zur Verfügung gestellt. 

Die Ausgangsroutine IEFUJV überprüft die Abrechnungsnummer 
der JOB-Anweisung, aktualisiert das Anzeigerbyte der Steuer- 
tabelleneintragung: und kontrolliert die Limite der zu über- 
wachenden Ressourcen. Sie teilt der Jobverwaltung mit, daß 
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ein Job nicht abzuarbeiten ist,’ wenn 


- die Abrechnungsnummer nicht vorhanden bzw, nicht regi- 

striert oder \ 

- eine der überwachten kritischen Ressourcen erschöpft 

ist. . 
In den Spalten 73...80 der JOB-Anweisung wird eine Diagnose- 
nachricht ausgegeben und der Job. endet. mit JCL-ERROR. 

Die: Ausgangsroutine IEPACTRT wird zur Jobendebehandlung 
aktiviert. Die vom abgearbeiteten Job: verbrauchten Ressourcen 
werden durch die Unterprogramme RESS1 .... RESSB. berechnet: 
und von der Ausgangsroutine saldiert. Im Falle der Überschrei- 
tung eines Limits füm eine der kritischen Ressourcen wird das 
entsprechende Anzeigerbit. gesetzt. Die Unterprogramme RESS1 
bis RESSB werden vom Anwender programmiert und müssen als 
Programmabschnitte vorliegen. Die Ausgangsroutine erstellt. 
eine Information über den Stand der Ressourcenbenutzung 
(Plan- und Istwerte). Diese wird vom Separatorprogramn des 
Ressourcenüberwachungssystems im Kopf der Druckerausgabe dem 
Nutzer mitgeteilt. 

Für die Ressource ZE-Zeit steht das Standardprogramm RESS! 
zur Verfügung. 

Eine der wichtigsten kritischen Ressourcen ist Druckerpa- 
pier. Der Druckerpapierverbrauch kann nur durch Routinen des 
Systemausgabeprogramms registriert werden. Zum Überwachung. 
der Ressource Druckerpapier kann der: modifizierte Modul 
IEPSDY85 in Verbindung mit dem Standardunterprogramm RESS2 
benutzt werden. 

zur Generierung, Wartung. und zum Abziehen der Nutzerdatei 
stehen die Dienstprogramme USERINIT, USERUT und USERIMP 
zur Verfügung. 

Das Dienstprogramm USRINIT legt die Nutzerdatei an, Para- 
meter sind dabei die Anzahl der Nutzereintragungen und der zu 
Überrwachenden Ressourcen. 

Das Dienstprogramm USERUT gestattet es, Abrechnungsnummern 
hinzuzufügen oder zu streichen, Plan- bzw. Istwerte für die 
überwächten Ressourcen zu ändern und die Nutzerdatei auszu- 
drucken. 

Um möglichem Datenverlust vorzubeugen, kann mit dem Dienst- 
programm USERDMP die Nutzerdatei auf das Archivband der Res- 
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sourcenerfassung (SMF) abgezogen werden. Alle Informationen 
der Nutzerdatei werden als Nutzererfassungssätze aufgegzeich- 
net und können zur Wiederherstellung: der Nutzerdatei mit 


Hilfe des Programms USERIMP benutzt werden. 
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Heckert, Roland S : 


Spezifikation und Implementierung eines Sitzungsdienstes für 
Rechnernetze in der DDR 


Das mit der volkewirtscheftlichen Entwicklung einhergehende 
schnelle Anwachsen der Informationsmengen führte neben der 
breiten Anwendung rechentechnischer Mittel auch zu der, Forde- 
rung nach Möglichkeiten für ihren entfernten Verbund. Solche 
Möglichkeiten werden mit dem Aufbau von Rechnernetzen ge- 
schaffen. Mit der Bereitstellung. von Rechnernetzlösungen haben 
Anwender ein Mittel zur Realisierung ihrer spezifischen Kommu- 
nikationswünsche (Lastverbund, verteilte Datenbanken, Nutzung 
lokal nicht verfügbarer Gerätetechnik u. &.) zur Verfügung. 

Im Kombinat Datenverarbeitung wird seit einer Reihe von Jahren 
an der Entwicklung von Rechnernetzsoftware cearbeitet. Diese 
Arbeiten haben nit der Bereitstellung der Computer Communica- 
tion Software (CCS /1/) einen Stand erreicht, der sowohl im 
Rahmen des Rechnerkommunikationsrietzes als auch in Kombinaten 
und Betrieben außerhalb des KDV Rechnernetzanwendungen in 
volkswirtschaftlichem Maßstab zuläßt. 

Mit der Spezifikation und Implementierung eines Sitzungsdien- 
stes für Rechnernetze in der DDR. unternimmt der VEB LfA einen 
weiteren Schritt auf dem Wege zur Bereitstellung standardisier- 
ter Rechnernetzsoftwaro. Diese Entwicklung erfolgt in Zusan- 
menarbeit mit anderen Einrichtungen auf der Basis des OSI- 
Referenzmodells für den Verbund offener Systeme /3/,/4/ und ent- 
sprechenden Standards der Gemeinsamen Spezialistensektion 
Rechnernetze des ESER und SKR. 


Ein Großteil der Kommunikationsfunktionen, die in Raechner- 
netzen zur Verfüoung stehen,haben anwendungsunabhängigen 
Charakter. Es ist deshalb wichtig, dem Anwender &ine solche 
Schnittstelle zum Netz zur Verfügung zu steller, die es ihm 
gestattet die für seine spezifische Anwendung benötigten 
Funktionen auszuwählen sowie die Art und Weise der konkreten 
Realisierung der Kommurikationsfurktionen für den Anwender 
transparent zu gestalten. 

Ein weiterer wesentlicher Aspekt bei der Entwicklung von Rech=- 
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noetzsoftware ist die Möglichkeit der Uberwirdung von Inkonm- 
patibilitäten der im Netz zu integrierenden unterschiedlichen 
Hardware sowie der zwischen don lokalen Systemen laufenden Kon- 
munikationsprotokolle. Dies wird erreicht durch eine verbind- 
liche Festlegung der Kommunikationsprotokollabläufe und ‚Schritt- 
stellen im Netz mit Hilfe von Standards. 
Als international akzeptiert kann gegenwärtig das Modell der 
Internationalen Standardisierungsorganisation (ISO) für den 
Verbund offener Systeme (OSI) gelten. Hiernach läßt sich jede 
Verbundsoftware sinnvoll in 7 Ebenen, vom physikalischen 
Nivesu der Kormunikation (1) bis hinauf zur Anwenderschnritt- 
stelle (7) einteilen, wobei in jeder Ebene bestimmte Funktionen 
unter Nutzung der Funktionen der darunterliegenden Schicht 
realisiert werden, die dem Nutzer dieser Ebene an der oberen 
Schnittstelle als Dienste zur Verfügung gestellt werden. Die 
innerhalb einer Ebene ablauferde Kommunikation zwischen den ein- 
zelner am Verbund beteiligten Systemen werden Ebenenprotokoll 
genannt und sind in Eberenprotokollstandards spezifiziert. 
Die Kommunikation zwischen benachbarten Ebenen in einem System 
erfolgt durch den Austausch vor Schnittstellenanweisungen, SOo- 
genannten Dienrstprimitiven. Der Nutzer einer Ebene kann dadurch 
zielgerichtet Kommurikationsfunktionen dieser Ebene auslösen. 
Die Dienstprimitive selbst urd ihre sinnvolle Areinanderreihung ° 
zur Realisierung von Kommunikationsaufgabon sind in entsprechenden 
Dierstdefiritionen für jede Ebene beschrieben. Durch die 
Standardisierung von Protokollen und Schrittstellenaktionen in 
jeder Ebene worden folgende Vorteile erreicht: 
- Verschiedene Implementierungen dos Protokolls einer Ebene 

sind konpatibol. 
- Die Implementierung der Software aufeirander aufbauender: 

Ebenen ist problemlos in verschiedenen Einrichtungen möglich. 
- Verschiedene Implementierungen einer Ebene sind gegeneinander 

eustauschbar. 


Besonders der zweite Aspekt ist für die Rechnernetzent- 

wicklung in der DDR von Bedeutung. 

So wird gegenwärtig auf der Grundlage vorhandener urd neuer 
allgemein verfügbarer Datendienste ein Transportdienst 

(Ebene 4) auf oinem Mikrorechnersystem (TSR/A) implementiert, 
der als front/end procossor jedem ar Verbund boteiligten Rechner 
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oder Terminal vorgelacert ist. Im Sinne des OSI-Ebenenmodells 


"darüber" ist der Sitzungsdienst angesiedelt auf den im fol- 
genden näher. eingegangen wird. Parallel zur Entwicklung des 
Sitzungsdienstes wird an der Entwicklung eines Fileservice 
gearbeitet, der die Funktionen des Sitzungsdienstes nutzt und 
auf dessen Grundlage dem Anwender eine breite Palette von Netz- 
diensten zur Verfügung gestellt wird. 

Der Sitzungsdienst nutzt die Dienste der Transportschicht. 

Dies sind im wesentlichen: 


- die Ende-zu-Ende-Steuerung zwischen den Systemen, deren 
Anwendungsprozesse miteinander zu kommunizieren wünschen, 

- die trarsparente Übertragung der Datenströne über eine 
Transportverbirdung in beiden Richtungen, 

- sowie die Loslösung von Kenntnissen über das konkrete urter- 
liegende Netz. 


In der Sitzungsschicnt sind alle Dienste enthalten, die für die 
Kommunikation zwischen Anwendungsprozessen in einem Rechnernetz 
erforderlich sind ohne anwendungsspezifische Funktionen zu ent- 
halten. Die Funktionen des Sitzungsdionstes bilden damit die 
Grundlage für Entwicklungsarbeiten für die Schichten 6/7 unab- 
hängig davon, welche Netzdienste implementiert werden sollen. 
Der Sitzungsdienst stellt an seiner oberen Schnittstelle Dien- 
ste für den organisierten und synchronisierten Datenaustausch 
zwischen kooperierenden, einen Dialog führenden Nutzern bereit. 
Es warden Mittel für: 


a) dem Aufbau einer Verbindung mit einem anderen SS-Nutzer, 
den Datenaustausch mit diesem Nutzer in einer abgestimnten 
Art und Weise und die geordnete Auflösung der Verbindung, 


b) die Abstimmung der Nutzungsrechte bestimmter Dienste für den 
Austausch von Daten, die Synchronisation und Auflösung der 
Verbindung sowie die Festlegung des Datenaustausches im 
Duplex- oder Halbduplexmodus 


c) das Einfügen von Synchronisationspunkton in einem Dialog und, 
nach Fehlern, die Wiederaufnahme des Dialogs von einem Syn- 
chronisatiorspunkt an 
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d) die Unterbrechung eines Dialogs und spätere Wiederaufnahme 


an einem vorher vereinbarten Punkt. 


bereitgestellt. 

Bei Sitzungsverbindungsaufbau werden die Regeln des Dialogs 
zwischen den beiden kommunizierenden Nutzern des Sitzungs- 
dienstes vereinbart. Dies geschieht durchs 


- eine Abstimmung über die Auswahl von Teildiensten des 
Sitzungsdienstes für den Dialog auf dieser Verbindung (Aus- 
wahl und Vereinbarung von Funktionseinheiten) 

- eine Abstimmung über das enfängliche Nutzungsrecht bestimmter 
ausgenählter Teildienste (Tokenkonzept) und 

- die Vereinbarung einer bestimmten Dienstqualität. 


Die Auswahl der Funktionseinheiten durch die Sitzungsdienstnutzer 
bestimmt die Möglichkeiten der Synchronisation ihrer Datenüber- 
tragung. In den Datenstrom können durch den Nutzer Synchronisa- 
tionspunkte eingefügt werden, .die eine Strukturierung des Daten- 
stromes, eine ständige Kontrolle der Synchronität der kommuni=- 
zierenden Nutzer sowie bei Fehlern Resynchronisetion ermöglichen. 
In Abhängigkeit von den in einer Spezifikätion oder Inplenen- 
tierung unterstützten Funktionseinheiten werden Subsets des 
Sitzungsdienstes unterschieden. Solche Subsets werden gebildet 
aus solchen Funktionseinheiten, die für einen bestimmten Anwen- 
dungstyp benötigt werden und unterscheiden sich im Grad ihrer 
Komplexität und Kompliziertheit wesentlich. In den Sitzungs- 
dienststanderds (/4/,/5/) werden drei solcher Subsets defi- 
niert. Br 

Die seit 1904 im VEB LfA laufenden Spezifikationsarbeiten Zum 
Sitzungsdienst und -protokoll erfolgen in Anlehnung an einen 
dieser Subsets, den Basic Synchronized Subset (BSS). Damit 
werden zum einen die wesentlichen, heute absehbaren Nutzer- 
forderungen hinsichtlich der zu unterstützenden Teildienste 
abgedeckt, zum anderen wird damit die Voraussetzung geschaffen, 
Implementierungen mit diesem Leistungsumfang in den nächsten 

2-3 Jahren, d. h. in überschaubaren Zeiträumen, zuü realisieren. 
Ein erster Entwurf der Schnittstellenspezifikation im Umfang 

des BSS lieot vor. Die Protokollspezifikation wird mit Hilfe 
allgemeiner Beschreibungsmittel (endliche Automaten, PDL /6/, 
FDT /7/, PSDN /8/) vorgenommen, wobei eine entgültige Entscheil- 
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dung für eine der Spezifikationstechniken noch nicht gefallen 
ist. Auf der Grundlage fertiggestellten Spezifikationsteile 
nird parallel dazu eine erste Implementierung des Sitzungs- 
dienstes mit gegenüber der Spezifikation eingeschränkten 


Leistungsumfang auf ESER-EDVA vorgenommen. Diess Implemen- 
tierung entspricht dem Basic Combined Subset für Halbduplex- 
betrieb und wird noch in diesem Jahr verfügbar sein. Einer 
späteren Erweiterung der unterstützten Teildienste steht bei 
sorgfältiger Umsetzung der Spezifikationsteile und entsprechen- 
den logisch/funktionalem Konzept nichts im Wege. Die logisch 
funktionale Struktur der Sitzungsdienstsoftware ist in der fol- 
genden Abbildung dargestellt. 


? 


/ . 
lokale Prozeßkommunikation vom/zum 
/ Sitzungsdienstnutzer y 
EEE FENDER NE 


SESSION 
PROTOCOL 


ESER-EDVA 
(Procedures 


| 


ZILK 
[7772 UPWARD PROCESSOR 


zzzz2) Datenschnittstelle 8 
—) Steuerungsübergabe, 
Abb.s logisch/funktionale Struktur der Sitzungsdienstsoft- 


ware und ihre Einbindung in die Implementierunasun- 
gebung £ 
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Grob ist die Struktur in die Teile 
- COMMON INPUT HANDLER 
= SESSION PROTOCOL MACHINE und 
- COMMON OUTPUT HANDLER 


gegliedert. 


COMMON deshalb, weil diese sowohl die Eingaben bzw. Ausgaben 
von/an den Trensportdienst als auch die Sitzungsdienstnutzer 
vehandeln. j 
Hereinkommende Anweisungen werden bei syntaktischer Richtigkeit 
in Abhängigkeit von ihrer Herkunft an den UPWARD (von TS)- 

oder DOWIWARD- (von SS-Nutzer)-PROCESSOR weitergeleitet. 

Diese sind Bestandteil der SESSION-PROTOCOL MACHINE und haben 
die Aufgabe diese Eingaben in Bezug auf die in einer konkreten 
Implementierung vorhandenen Beschränkungen hin zu prüfen sowie 
die parallele Verwaltung einer Vielzahl von Verbindungen zu 
organisieren. pie parallele Verwaltung von Verbindungen wird 
über Steuerblöcke und Steuerblockzeigerlisten realisiert. 

Im Kern der SESSION PROTOCOL MACHINE werden dann die eigent- 
lichen Aktionen zur Realisierung des Sitzungsprotokolls ent- 
sprechend der ISO-Protokollspezifikation ausgeführt. 

Ausgaben zur Realisierung des Sitzungsprotokolls oder Anweisungen 
zur Meldung lokaler Föhler (Syntax u:5.) werden im COMMON OUTPUT 
HANDLER generiert und an die jevieiligen Prozesse ausgegeben. 
Der ADAPTER realisiert zum Sitzungsdienst hin die Übergabe bzw. 
Übernahme von Schnittstellenanweisungen von/an den TS, und zum 
TS hin den Lese/Schreibzugriff zum Transportdienst auf den 
front/end-processor. Dieses Strukturkonzept ist so angelegt, 
daß keine der genannten Funktionen an eine spezielle Imple- 
mentierungsumgebung gebunden ist. Damit stehen der Implemen- 
tierung dieses Konzeptes in verschisdenen Hardware-/Betriebs- 
systemumgebungen keine erkennbaren Schwierigkeiten entgegen. 
Neben ESER ist als nächstes die Implementierung auf K1630 vor- 
gesehen. Für die Programmierung ist die Sprache C vorgesehen, 
um die Portierung der Software zu erleichtern. 
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Klaus Koehler 
Formatunabhaengige Daten-Ein-und-Ausgabe in FORTRAN 0S/ES 


1. Einleitung 


In der praktischen Nutzung von Rechenanlagen fuer wissen. 
schaftlich-technische Zwecke sowie fuer die Aus- und Weiter- 
bildung ‚nimmt nach wie vor die Programmiersprache FORTRAN 
eine dominierende Rolle ein. Die Erfahrungen zeigen, dasz 
speziell die Behandlung der Daten- Ein. und Ausgabe eine 
Reihe von Handhabungsmaengeln sowohl aus der Sicht der An 
wendung als auch der Aus- und Weiterbildung zeigt. Die Ur. 
sachen liegen vor allem in dem starren FORMAT_-Könzept be 
gruendet : fe 

- Hoher Ausbildungsaufwand 

- Hoher Programmieraufwand 

- Formatgebundene Dateneingabe entspricht nicht Dialog. 

erfordernissen 


Aus diesem Grunde wurden die nachfolgenden Konvertierungs- 
routinen mit folgenden Zielstellungen konzipiert : 

- Formatfreiheit fuer Eingabedaten 

- Standardformate fuer Ausgabedaten 

- Unterstuetzung der E/A von CHARACTER-Daten 

- Wegfall von FORMAT-Anweisungen im Anwenderprogramm 

- Portabilltaet fuer Anlagen mit FORTRAN-Compilern 


= 


2. Konzeption der formatunabhaengigen E/A 
2.1 Numerische Daten 


Die Dateneingabe wird durch ein FUNCTION-Unterprogramm reali- 
siert.- Der Inhalt einer Datenkarte von 80 Zeichen Iaenge wird 
zunaechst in einen Eingabebereich im Format ( 8041 ) eingelesen 
und beginnend ab Spalte 1 auf Zeichen ungleich "Blank! unter. 
sucht. Ab dieser "aktuellen Position! wird versucht, die nach- 
folgende Zeichenkette als reelle Variable zu interpretieren. 
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Dabei werden eventuell vorhandene Sonderzeichen "Dezimalpunkt', 


"Plus! bzw. "Minus! mit einbezogen. Die Sonderzeiohen muessen 
entsprechend der FORTRAN_. Syntax positioniert sein. Die Analyse 
und Konvertierung endet beim Auftreten von "Blank! oder 'Komma' 
bzw. beim Erreichen der Spalte 80. Im Anwenderprogram erfolgt 
die Zuweisung und gegebenfalls Typumwandlung des Funktionswertes 
an die entsprechende Variable. 

Bei Wiedereintritt in die FUNCTION wird die Analyse an der 
aktuellen Position fortgesetzt. Wird bei der Konvertierung des. 
Eingabebereichs die Spalte 80 erreicht, folgt das Einlesen einer 
neuen Karte und das Einstellen der aktuellen Position = 1. 

Eine gesonderte Fehlerbehandlung erfolgt beim Erkennen unzu- 
laessiger Zeichen im Eingabebereich, bei Zahlenbereichsueber-. 
schreitung, E/A-Fehlern und Erxeichen des Datelendes vor dem 
logischen Ende. 


Die formatunbhaengige Ausgabe im Standardformat ist als SUBROU.- 
TINE konzipiert. Durch ihren Aufruf wird der Argumentwert vom 
Typ INTEGER*4 bzw. REAL*4 in ein Standardformat konvertiert 
und in einen Ausgabebereich von 120 Zeichen Iaenge beginnend 
ab Druckposition 1 gestellt. Der Ausgabebereich wird gedruckt 
wenn.die Postion 120 erreicht ist . Die Konvertierung von reel- 
len Groessen erfolgt in Abhaengigkeit von ihrem Wert entweder 
in das F_ oder E-Format. 

Eine Fehlerbehandlung erfolgt bei E/A_Fehlern oder bei Errei- 
chen des Dateiendes. ö 


2.2 CHARACTER -Daten 

Der Funktionsaufruf zur Eingabe von Zeichenkettendaten reali- 
siert die Zuweisung des an der aktuellen Position befindlichen 
Zeichens ( unabhaengig vom Wert ) an eine Variable im Anwender. 
programm. 

Bei der Ausgabe wird der Argumentwert als Zeichenkette im For- 
mat ( Ali ) in die aktuelle Position des Ausgabebereichs ge- 
stellt. Eine Konvertierung erfolgt nicht. 
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2.3 Sonderfunktionen 


Es ist moeglich, bei der Eingabe nach der Konvertierung sofort 
auf eine neue Karte ueberzugehen, bevor die Position 80 des 
Eingabebereichs erreicht ist. 
Zur Gestaltung der Ausgabe werden folgende Sonderfunktionen 
bereitgestellt : 
- Druck der Zeile vor vollstaendiger Belegung des Ausgabe 
bereichs 
Ausgabe Leerzeile(n) 
- Vorschub auf neue Seite 
— Einfuegen von Leerzeichen in den Ausgabebereich ab aktu- 
eller Position 


3. Realisierung 


Die Konvertierungsroutinen fuer formatunabhaengige Daten. Ein. 
und „Ausgabe sind in FORTRAN geschrieben und damit prinzi- 
piell fuer alle Anlagen verfuegbar, die einen FORTRAN-Compiler 
besitzen. Im Betriebssystem OS/ES erfolgt die Eingabe ueber die 
Datei 5 und die Ausgabe ueber die Datei 6. 
Der Speicherbedarf liegt im OS/ES fuer die Eingaberoutinen bei 
ca. 3 K Bytes und fuer die Ausgaberoutinen bei ca. 4 K Bytes. 

Folgende Routinen stehen z.2t. zur Verfuegung : 

GET _ Eingabe einer numerischen Variablen " 

GETLN — analog GET ,„ Vebergang zu neuer Datenkarte 

GET — Eingabe einer Zeichenkettenvariablen 

GETCLN — analog GEIC, Vebergang zu neuer Datenkarte 

PUTIN . Ausgabe einer REAL_Variablen ( FORMAT (1X,F11.5)) 

PUTNLN — analog PUTIN ,„ Druck Ausgabebereich 

PUTI - Ausgabe einer INTEGER-Variablen (FORMAT(4X,I8)) 

PUTILN — analog PUTI ,„ Druck Ausgabebereich 

PIC — Ausgabe Zeichenkettenwert ( FORMAT(A1)) 

PUTCLN — analog PUTC „ Druck Ausgabebereich 

LESEN — Einlesen naechste Datenkarte 

LINE — Druck Ausgabebereich bzw. Leerzeile 
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BLANK — Einfuegen von n Blanks in Ausgabebereich 
PAGE — Vorschub auf neue Seite 


4. Beispiel 


C DEMONSTRATIONSBEISPIEL FORMATFREIE D/A 
REAL A,B,C,DELTA, TEXT,X,X0,X1,Y 
DIMENSION TEXT(80) 


DO 100 I=1,80 
TEXT(I)=GETC (DUMMY) 
IF ( I .EQ. 40 ) CALL LESEN 
100 CONTINUE 


A =GET (DUMMY) 
B =GET(DUNMY) 
C =GET(DUMIMY) 


X0 =GET(DUIMY) 
X1  =GET(DUM) 
DELTA=GET (DUMMY) 
DO 200 I=1,80 
CALL PUTC(TEXT(I)) 
IF ( I .EQ. 40 ) CALL LINE 
200 CONTINUE 
CALL LINE 
X=X0 
I=1 
250 CONTINUE 
IF(.NOT.(X.LE.X1)) GOTO 300 
Y=A*X**2 + B*X + C 
CALL PUTI(I) 
CALL PUTN(X) 
CALL PUTNLN(Y) 
X=X+DELTA 
I=I+1 
GOTO 250 
300 CONTINUE 
END 
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Datenaufbau 
FUNKTION Y= A*X**2 + B*HZX + C ( Karte 1 ) 
I X Y ( Karte 2 ) 
15,20,-3.2 ( Karte 3 ) 
=100 10000 ( Karte 4 ) 
10 ( Karte 5 ) 
Druckbila 


zszzmau2u22 


FUNKTION Y= A*rX**2 + B+X + C 
I x Y 
1 -100.00000 : .14800E+06 . 
2 -90.00000 .11970E+06 


11 0.0 -3.20000 
12 10.00000 1696.80000 


5. Zusammenfassung 


Die beschriebenen Konvertierungsroutinen erlauben den Wegfall 
der formatgesteuerten Ein-/ Ausgabe im Anwenderprogramm. Die 
formatfreie Eingabe ist vor allem fuer Dialogprogramme sehr 
nutzerfreundlich. Die Portabilitaet der Routinen ist fuer Anla- 
gen mit FORTRAN Compiler problemlos gewaehrleistet. 


Verfasser : Dipl.-Ing. Klaus Koehler 
Ingenieurhochschule Zittau ” 
Abt. EDV und Rechentechnik 
8800 Zittau 
Th.-Koemer-Alle 16 
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PDL . Bin sprachlich-orientierter Ansatz zur Spezifikation 
. und Verifikation von Rechnernetzprotekellen. 


1, Einleitung 


Der .Spesifikation von Rechnernetzprotokollen wird gegenwärtig. 
große. Aufmerksamkeit entgegengebracht. In der Literatur werden 
verschiedene Ansätze vorgeschlagen, die sich in einer Vielsehl 
von Methoden /Sunshine 82/,/Rudin 83/ niederschlagen. Trotz 
dieser Vielfalt hat bisher keine Methode eine breite Anwendung 
gefunden, 

Dafür gibt es mehrere Gründe... Viele Methoden haben noch experi- 
mentellen Charakter. und bedürfen weiterer Entwicklung. Auch 
solche Gründe wie das. Fehlen von definierenden Berichten und. 
Handbüchern, :wie.sie.z.B, bei Pregrammierspraehen üblich sind, 
sowie. der Unterstützung durch Organisationen müssen. genannt 
werden, Ein sehr .wesentlicher Aspekt ist auch die Hutzerakzep- 
tenz. Viele Methoden. sind unserer Meinung zu konplisiert, um 

eine breite. Anwendung zu. finden. Weitere. Untersuchungen werden 
erforderlich sein, um den Anforderungen der Protokellspezifika- 
tion bösser gerecht zu werden. Dabei ist es notwendig, mehr 

die Gemeinsamkeiten existierender Methoden zu nutzen als ihre 
Unterschiede herauszuerbeiten /Danthine 80/, 


Die eprachlich-oerientierte Spezifikation von Rechnernetz-Proto- 
kellen ist einer der wichtigsten Ansätze, die zur Zeit disku- 
tiert werden /Eünig .84/. Die Vorteile dieses Ansatzes, wie 
Bzaktheit und Vellständigkeit der Beschreibung, ‚Unterstützung 
einer schrittweisen Protokollentwicklung vom Entwurf. bis zur 
Implementisrung, sind 1... anerkennt. Hauptansatz der Kritik en 
dieser Hethode ist die Gefahr einer zu implementierungsnahen 
Beschreibung sowie die mögliche Belastung des Anwenders mit. 
Deteils, die dureh die Regeln der Sprache bedingt. sind, aber 
keine Relevanz für die Protokollbeschreibung besitzen. Die her- 
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koemmlichen höheren Programmiersprachen sind Jedoch nicht vor- 
rangig für die Protokollbeschreibung entworfen worden und 
können somit auch nicht allen Anforderungen genügen, Wir sind 
der Meinung, daß hierfür Spezialsprachen entwickelt werden 
müssen, die die oben erwähnten Gefahren ausschließen, 


Mit PDL (Protocol Description Language) /König 85a/ wird ein. 
solches Sprachkongept bereitgestellt, das auf modernen Erkennt- 
nissen der Sprachentwicklung beruht, Es bildet den Kern eines 
Systems zur automatengestützten Protokollentwicklung /König 85b/, 
das den Entwurf, die Verifikation und die Implementierung ven. 
Rechnernetzprotokollen unterstützt. Im folgenden sellen ausgehend 
von den Erfordernissen der Protekollspezifikation sprachliche 
Aspekte der Gestaltung von PDL diskutiert werden, 


2, Gestaltungsprinzipien von PDL 


Die Gestaltung der Sprache. ist durch die Anforderungen an die 
Protokollspezifikation bestimmt. 


Die Hauptaufgabe der Protokollspegzifikation ist die Dokunents- 
tion des .Protokollentwurfs als Grundlage für eine. einheitliche 
Interpretation des Protokolls bei der weiteren. Realisierung, Der 
Protokollentwurf. hat funktionellen Charakter und zielt nicht .auf 
eine konkrete Implementierung. Zu seinen Aufgaben gehört z.B. 
die Bestimmung der Dienste einer Schicht, der möglichen Ereig- 
nisse und des Kommunikationsverlaufs, Zugleich wird mit der Spe- 
sifikation auch. ein Mittel zur Verständigung zwischen.mehreren 
en der Hetzentwicklung beteiligten Partnern. geschaffen. Ein wei- 
terer Aspekt, der. unserer Meinung in Anbetracht der suneist.. 
verbal beschriebenen Protekell-Standaräs sehr wichtig int, be- 
steht darin, daß eine (geeignete) formale Beschreibung wesent- 
lich zur Anschaulichkeit und zum Verstiindnis der Protokollab- 
1äufe beiträgt. 


Für die Gestaltung. einer Beschreibungssprache ergibt. sich da--.. 
zaus die.Forderung, einfache und problembesegene Ausdrucksmittel 
su scheffen, die das Wesen des Protokellablaufs widerspiegeln, 

ohne ‚diesen mit implementierungsebedingten Details bzw. -kompli- - 
zierten Sprachregeln zu belasten, Die sprachlichen Hittel müssen 
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vertraut und leicht erlernbar sein und zugleich eine umfassende, 
eindeutige und gut leshare Protokollbeschreibung gewährleisten. 


Eine Protokollbeschreibungssprache soll nicht nur zur Dokumenta- 
tion dos fertigen Entwurfs dienen, sondern auch bei dessen Ent- 
wicklung Anwondung Zinden. Es muß möglich sein, gewisse. Entwurfe- 
entscheidungen zurückzustellen baw, Entmirfsalternativen darzu- 
stellen. 


Dia Protokollspezifikation sollte auch die nachfolgenden Fhasen 
der Protokollentwicklung, vor allem die Verifikation und die 
Inplementisrung, unterstützen. Das bedeutet, daß die Protokoll- 
boeschroibungssprache so zu gestalten ist, deß zum. einen eine. 
oentwurfsbogleitende Verifikation ‚und zum anderen eine relativ 
goradlinige Abbildung der Spezifikation auf die Implementierung 
möglich sind. /Bolt.80/. Eine Automatenunterstütsung ‚dieser. Pro- 
zesso ist wünschenswert und wird. zunehmend angestrebt. Eins 
sprachlich geführte Protokollspegifikation bildet hierfür eine 
günstige Ausgangebasin, 

) 


Ä 


3. Sprachliche Aspekte der Gestaltung von PDL 


Die Umsetzung obiger Gestaltungsprinzipien führte u.a, zu folgen- 
den Entwurfsontscheidungen. 


PDL versucht wichtige. Begriffe des 0OSI»Referenzmodells /ISO.81/, 
wie 5.B, ‚Schicht, Einrichtung, -Dienst und Protokoll, mit sprach- 
lichen litteln zu Zassen, Damit wird gleichzeitig ein sprach- 
liches Hodell für den OSI-Protokollmechanismus geschaffen, 


PDL orientiert desweiteren auf. eine Beschreibung. des Protokoll- 
eblaufs und nicht auf die Beschreibung von: Zustendsübergängen, 
wie sie für viele Hothoden üblich ist, Letztere. (siehe. z.B. 
/Bolt 80/) beschreibt i,a,. das. Verhalten. von Binrichtungen. 
mittels ondlicher Zustandsautomaten.. Eine solche. Beschreibung 
widerspiegelt nicht immer eindeutig den Kommunikationsyerlauf, 
(Be.gibt hier gewisse Ähnlichkeiten.mit der sogenannten goto- 
Progrermierung) Die PDL-Spezifikation dagagen srewingt. sine 
fortlaufende (goto=treio). Beschreibung. der. Wechselwirkung. 
swischen paaren Einrichtungen, Wir glauben, daß diese ablauf- 


orientierte Darstellung natürlicher und adäquater den Protokoll- 
verlauf beschreibt, j 


PDL hat deskriptiven Charekter, Es enthält eino Reihe. von Spraeh- 
elementon.und .-regelungen, die von. vörnherein.eino inplenen” 
tierungsorientierte Darstellung verhindern, Die-deskriptiven Elo- 
ments können entsprechend den aktuellen:Beschreibungs- bzw. Ab- 
straktionsnivrean schrittweise vorfeinert worden. 


Im’ folgenden soll die Gestaltung der wichtigsten Elemente von 
PDL etwas ausführlicher betrachtet werden, 


3,1, Die Schicht 


Das. OSI-Referenzmodell basiert auf einer. Henge Üübereinanderlie- 
gender. Schichten, Eine Schicht umfaßt einen logisch zusannen- 
hüngenden Bereich der Rechnernetzsoftware, der ein. spesifinches 
Aufgabenspektrum erfüllt, Jede Schicht stellt der darüberliegen- 
den einen. Satz von. Diensten zur Verfügung, die. diese.zur Reali- 
sierung ihrer Aufgaben nutzen kann. Die interne Funktionsweise 
seiner Schicht .ist autonom und nach außen nicht sichtbar. Damit. 
kann eine Schicht prinzipiell.durch. seine: andere ergetzt werden, 
tells. die zugehörigen Anschlußbedingungen (Dienste) gerähr- 
leistet werden, Die Schicht (leyer) wurde deshalb auch als 
Rahmen für die PDL-Spezifikation gewählt, 


Vorgleicht man die Charakteristika einer Schicht nmit.den Herk- 
malen abstrakter Datentypen, so stellt man eine weitgehende 
Übereinstimmng fest, PDL baut hierauf auf und realisiert. die 
layer in Form eines abstrakten Datoentyps. Die Dienste (seryice) 
der Schicht entsprechen dabei den Funktionen des abstrakten 
Datentyps, während ihre "Implementierung" durch die kommuni- 
sierenden Einrichtungen (entity) realisiert wird. Das Besonders 
dieses "abstrakten Datentyps" besteht darin, daß. die. "Implonen- 
$ilorung" verteilt ist, Beispiel 1 zeigt den konkreten Aufbau 
einer layer. | 
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028 el 13 
layer ABj. 
gexvioe asked. AB-SEND request(datas data block); 
 Zesponsed AB-RECEIVE indicationj 


message PDU: reoord(data: data block; control bit: bit); ' 


pretoool AB-Protoeol: Bend<=>receive; 
entity AB-B} 


Fasz {un} 
erlayer [ab] 


322, Die Binrichtung 


Die ‚Einrichtungen bilden die "Kommunikationszentralen" der 
Schicht... Sie..nehmen. die Aufträge, die an die Schicht Übergaben 
werden, an.ünd. veranlassen ‚durch Wechselwirkung init anderen 
Binrichtungen: der.Schicht ihre Erfüllung... PDL modslliert. eine. 
Binrichtung..(entity) ebenfalls durch einen abstrakten Datentyp. 
(Diese.Interpretation weist. gewisse Ähnlichkeiten mit.der.Pro- 
soss-Auffassung in Conourvent Pascal /Brinch Hansen 77/ auf.) 
Dio. ent4$y-Spazifikation besteht entsprechend aus einar.Be-. 
schreibung.. der Komponentsn der. Einrichtung (Datenstrukturen, . 
ginor),. einschließlich der Schnittstelle (eintreffonde Dienste 
und .Nachrichten), und seinem Aktionsteil dor das dynamische. Ver- 
halten.der Einrichtung festlegt. Pür.die Beschreibung. des .dyna- 
mischen Verhaltens der Einrichtung. wurde mit der par event-An- 
weisung.soine spezielle Variante der .guarded regions /Brinch 
Hensen 79/ entwickelt, Die. pag event-Anweisung besteht aus einer 
Menge..von -Breignie-Aktionsfolgen, die parallel .ausgeführt werden 
können, Die Ausführung einer Aktionsfolge (i,a, .die Ausführung 
eines Protokolls) wird durch Eintreten des zugeoräneton Ereig-- 
nissen (z.B. die Aktivierung eines Dienstes oder das Eintreffen 
einer Nachricht) ausgelöst. Solange kein solches :Ereignis vor- 
liegt bzw, nach Ausführung der Aktionsfolgen wartet die Ein- 
richtung auf das Eintreten neuer Ereignisse, 
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Beispiel 2: 


entity AB-E; 

service AB-SEND request; 

message PDU; 

protocol part send, receive; 

per oyent n 
AB-SEND request: send | 
PDU«- AB-E: receive 

#F2er 

Zentity fAB-Ef 


3.3, Dienste und Protokolle 


Die Dienste bilden die Ropräsentanten der Schicht nach außen, - 
Ihre Spezifikation unterteilt sich.in eins.Nu$tser-.und eine Kon- 
textspezifikation, Die Hutzerspezifikation, sie ist in .PDL Be- 
standteil der layer-Spezifikation (siehe Beispiel:1), gibt an, 
wie ein Dienst zu. aktivieren.ist, In.PDL geschieht das durch 
Angabe des Dienstprimitivs und der zugehörigen. Paranster, wobei. 
zwischen Diensten unterschieden wird, die von der oberen Schicht 
aktiviert werden (asked) und.solchen, die in der eigenen. Schicht 
initilert werden (responsed). Die Kontextspezifikation de» 
schreibt den Zusammenhang zwischen den Diensten, Sie int z.2. 
noch nicht in PDL enthalten. Hierfür sind unserer Meinung . 
endere Darstellüngsmittel erforderlich. /König 85b/, die die 
sprachliche Spezifikation ergänzen müssen, 


Ein Dienst wird innerhalb. der Schicht dureh die Funktionen der 
Schicht, die ihrerseits. in den meisten Fällen Protokellab- 
schnitte darstellen, und. unter -Inanspruchnahme der Dienste der 
derunterliegenden Schicht realisiert /ISO 81/. In PDL wird 
dieser Sachverhalt dadurch wiedergegeben, daß der Aufruf. eines 
Dienstes, dargestellt als Ereignis in.der par event-Anweisung, 
den .Aufruf eines Protokoll-Teils(protoecol part) bewirkt, Ein 
Protokoll-Teil (sie werden aus.Gründen der Übersichtlichkeit. 
im Anschluß. an die layer-Spezifikation.angeordnst) beschreibt - 
den Kommunikationsverlauf aus der Sicht der Einrichtung (siche 
Beispiel 3). Der Kommunikationspartner wird dabei durch eine 
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Beispiel 3: 


protocol part send(entity receiver); 
service AB-SEND. indication; 
message PDU to receiver, 
ACK from receiver; 
timer t: 0..60; 
bogin 
PDU --> receiver; 
start(t); 
wait event 
ACK d=- receiver: ,„ « . 
response AB-SEND indication; 
“ ® . 
timeout t: skip 
Frelti 


aa fund 


fiktive Einrichtung, die im Kopf des Protokoll-Teils vereinbart 
wird, repräsentiert.: Der reale Partner-Protokoll-Teil wird. in 
der. proteeol-Spezifikation. der layer festgelegt. Die. Protokoll- 
Abarbeitung wird durch Aufruf eines Protokoll-Teils ausgelöst, 
Der zugehörige Partner-Protokoll-Teil wird durch Eintreffen. 
einer Hachricht von der das Protokoll initilerenden Einrichtung 
angestoßen. 

Obige. Interpretation. des Zusammenhanges zwischen Diensten. und. 
Protokollen, genaugenommen den Protokoll-Teilen, weist Ähnlich- 
keiten. mit dem Prozedur-Aufruf auf und unterscheidet sich von 
der.häufig anzutreffenden ausschließlichen Interpretation eines 
Dienstes ale Nachricht. Im Unterschied. zur-Prosedur gibt .es’ 
aber in..dieser Interpretation keins Ergebnisparameter, Hier- 
für stehen,- entsprechend dem OSI-Referenzmodell,. die Dienste 
zur ‚Verfügung, die durch .die Schicht initiiert, die. darüber- 
liegende Schicht. über bestimmte Ereignisse. ‚informieren. 
(zesponsed-Dienste). Auch hier gilt. die obige Interpretation, 
Der Aufruf eines solchen Diensten (response) stößt in der de- 
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rüberliegenden Schicht einen Protokoll-Teil an bzw, bewirkt die 
Fortführung eines Protokolls. 


3.4, Darstellung des Protokollablaufs 


Ein Protokoll beschreibt die Wechselwirkung zwischen paaren Ein- 
fichtugen. In Wirklichkeit wird diese virtuelle Wechselwirkung 

duch Inansprüchnahne der Dienste der dazunterliegenden Schicht 

zealisiert, PDL trägt diesen Sachverhalt Rechnung und führt swei 
Beschreibungsebenen - PDL/D und PDL/I » ein. 


PDL/D (D»Design) konzentriert sich auf die Beschreibung der. Kon- 
munikation zwischen paaren Binrichtungen, Die Realisierung der 
Kommunikation durch die darunterliegende Schicht wird dabei nur 
beschränkt betrachtet, Die PDL/D-Spesifikation soll vor allen 
‚während der Entwurfsphase und zur. enschanlichen Darstellung von 
Protokollabläufen Anwendung finden, Zu diesen Zweck wird PDL/D 
durch eine Reihe ven Sprachregelungen unterstütst, auf die 
weiter unten nech ‚singegangen wird, die den deseriptiven Charak- 
ter dieser Spezifikation unterstützen. 


PDL/I (I=Implementation) beschreibt die Komtunfkation swischen 
den paaren Einrichtungen unter Binbesiehung der Dienste der de- 
zunterliogenden. Schicht. Es soll vor ellen In der inplenen- 
tierungsvorbereitenden Phase eingesetst. worden, Die Sposifika- 
tion in. PDL/I schränkt die Freiheiten, die äje PDL/D-Spögifika- 
tion zullißt, ‚weitgehend ein.und ferdert:in HinbJick auf die In- 
plonentierung könkrete Entscheidungen, chne eine bentimite In- 
plementierung vorzuschreiben, j 


Der Protokollverlauf wird dureh Protekollanweisungen beschrieben, 
Die wichtigsten Protokellanweisungen. sind die Sende- (-->) und 
die wait ovent-Anweisung (siehe Beispiel 3). 


Die wait event-Anweisung stellt wie die par oevent-Anweisung eine 
modifizierte Form der guarded regions dar, Sie beschreibt das 
Werten und Reagieren auf gewisse Ereignisse (Eintreffen einer 
-Rachricht &--), timeout). In Öegensatz zur par eyent-Anweisung 
reagiert die wait event-Anweisung nur auf ein Ereignis, 
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Desweitesen gibt es Anweisungen für das Starten und Rücksetzen 
von Tinern, für Wertzuweisungen, für das Eintragen (<:=) und 
Löschen (>i=).von Daten.in komplexeren Datenstrukturen, 2.B. 
Hechrichten, und andere, Für die Beschreibung des Protokollab- . 
laufs stehen dio. bekannten. Steuerstrukturen höherer Programnier- 
sprachen, wio die if-, case- und.loop-Anweisung zur Verfügung. 
Außsrden besteht die Höglichkeit, gewisse Protokollaktionen nicht- 
fornalisiert mittels verbaler Konstruktionen zu beschreiben, 


Die Spezifikation in PDL/D. unterscheidet sich ven der in PDL/I 
noben der. bereits erwähnten Beschreibung der virtuellen Kommuni- 
kation (dargestellt durch --> und. <--) durch eine Reihe von 
Beglungen für eine stärker deskriptive Darstellung. So .gestattot 
PDL dis implizite Einführung beliebiger elementarer Datentypen, 
ale implizite Deklaration von Variablen in den Protokoll-Teilen 
und die wahlweise Angabe von Indizes in Datenstrukturen, Außer- 
dem gibt es keine sprachlichen IHittel für die Bildung arithne-.. 
‚ttscher und logischer Ausdrücke, Hierfür. nissen verbale Konstruk- 
tionen genutzt werden, Der deskriptive Charakter von.PDL/D ist 
jedoch nicht auf die genannten Regelungen beschränkt, Für Ak-. 
tionen.mit einer festen. Bedeutung wurde eine knappe und aussage» 
krüftige Symbolik. eingeführt, . Genannt seien hier u.a. die Sondo- 
Anweisung ("->), das Empfangsereignis (<--), der Aufruf eines 
zesponsed-Dienstes (response) und die Eintragungsenweisung (<ı=) 
(Letztere fordert im Gegensatz. zur Wertzuweisung, daß der Daten- 
typ der rechten Seite. lediglich &inem der Komponententypen der 
komplexeren Datenstruktur euf der linken Seite entspricht. )« 


PDL/I ersetzt die virtuelle Kommunikation durch die Anpassung an 
die untere Schicht. Zu diesem Zweck werden die Sende-Anweisung 
und das Empfangsereignis auf die Dienste dieser Schicht zurück- 
geführt. In Vorbereitung einer Implementierung müssen die des- 
kriptiven Elemente von PDL/D durch Einführung von Ausdrücken, 
Indizes, Datentyp-Definitionen u,a, verfeinert werden, Die 
Grundstruktur der PDL/D-Spezifikation bleibt jedoch erhalten, 
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325. Unterstützung der Verifika$ion 


Dis Gesamtkonzeption des in der Binleitung erwähnten Systems sur 

automatengestützten Protokollentwicklung sieht vor, die PDL-Spor» 

sifikation mittels Petri-Netzen zu verifizieren. Zu diesem Zweck 

wird die PDL-Spezifikation automatisch-in ein Petri-Nets trans- 

£ormiert, das anschließend analysiert. und simuliert wird (siehe 

hierzu /Heiner 84/). Auf diese Weise können Fehler in. logischen 

Entwurf entdeokt werden, Der PDL-Sprachentwurf unterstütst diose 

Sransfermation durch eine Reihe von Festlegungen. Hier wären 

UA, ZU Hennen 

- die Schnittstellen-Spezifikation (serrioe,mensage) in den. 
entity's und den protocol parts, durch die die Synchrenisa- 
tionsstellen relativ einfach sondiert werden können, 

- die angebötenen Steuerstrukturen, die klaren Petri-Netz- 
Strukturen entgegenkommen 

- und nioht zuletzt die mittels der angebotenen buw, ».Ewungenen. 
Hodularisierung mögliche Zerlegung bsw. Reduktion den Analysen, 


FR Schlußbemerkungen 


Die Diskussion der Gestaltungsprinsipien von PDL zeigt, daß.der 
Protokollmechanismms des OSI-Referenznodells unter Berücksichti- 
gung moderner Erkenntnisse der Programniersprachentwicklung und 
der parallelen Programmierung adäquat .mit sprachlichen Mitteln 
beschrieben. werden kein, Die Erfahrungen, die bei der Anwendung 
solcher Sprachen. gesammelt werden, müssen zeigen, inwieweit 

dio Kritik an der sprachlich geführten Spezifikation von Rechner- 
netsprotokellen noch gerechtfertigt ist, 
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Miller, K.; Piens, C. 


Simulation von Verwaltungsstrategien für den virtuellen Direkt- 
zugriffsspeicher des Systens SPOOL_3 


1. Ziele der Simulation 
Mit der Einbindung eines virtuellen Direktzugriffsspeichers 
(8. /1/) in ein Betriebssystem -— oder in ein mit diesen 
verbundenen Preschedulingsystem — kommt es zu einer Ver- : 
größerung des Overheads. Dieser Overhead resultiert zum 
einen aus der ständigen Arbeit des Vorwaltungssystens des vir- 
tuellen Direktzugriffsspeichers und zum anderen aus dem Auf- 
wend zur Bereitstellung der benötigten Dateien im Prinär- 
speicher. Durch die Simulation des virtuellen Direktzugriffs- 
speichers sollen im wesentlichen zwei Ziele verfolgt werden: 
(1) Unterstützung einer sinnvollen Dimensionierung von Prinär- 

und Sekundärspeicher, 
(2) Erleichterung der Auswahl von Strategien bzw. Algorithmen 

für 

- die Speicherplatzzuordnung, 

- die Dateieinlagerung, 

- die Datelauslagerung, 

- die Dateisicherung und 

- die Reorganisation des Sekundärspeichers. 
Gütekriterium soll der errechnete Gesamtaufwand für die not- 
wendigen Dateitransporte zwischen den Speicherebenen sein, 
der einerseits in Spuren pro Zeitintervall und andererseits 
in Belastungszeit pro Zeitintervall gemessen wird. 


2. Modellbeschreibung 

Das Modell wurde in PASCAL programmiert. Es simuliert die Ver- 
waltungskomponenten eines virtuellen Direktzugriffsspeichers 
nach /1/. Für jede Forderung, also für jedes Ansprechen einer 
Datei,eind der Standort der Datei zu bestimmen, die Benutzungs- 
statistik zu aktualisieren und falls erforderlich die nötigen 
Platzzuweisungs- und Transportoperationen durchzuführen, 

Durch Paramstersteuerung können die Dimensionen des Prinär- 

und des Sekundärspeichers, d.h. Anzahl und Kapazität der 
Magnetplatten und Magnetbänder, Simulationszeiträume und 
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Strategien für die Komponenten des Verwaltungssystens fest- 
gelegt werden. 

Die Speicherplatzsuordnung erfolgt in zwei Schritten. Zuerst 
erfolgt die Datenträgerausuahl - sie kann zyklisch, nach dem 
größten Freibereich, oder nach der Gesamtanzahl von freien 
Spuren erfolgen -, danach die Zuordnung von Speicherplatz 
auf dem ausgewählten Datenträger. Diese kann nach den Mo- 
thoden first-fit und best-fit orfolgen. Beim Scheitern der 
Eethode kann die Zuordnung von max. fünf Bereichen (Extent- 
bildung) ausgenählt werden. Zur Reduzierung der Speicher- 
fragnentierung können die Dateigrößen normiert werden. 

Für die Dateieinlagerung kann festgelegt werden, ob An- 
forderungen sofort erfüllt oder gepuffert werden, bis ein 
Zeitintervall abgelaufen ist oder eine bestimmte Anzahl von 
Anforderungen wartet. 

Die Dateiauslagsrung kann mit und ohne Bildung von Reserve- 
mengen erfolgen. Für die Festlegung der Reihenfolge der 
auszulagernden Dateien stehen mehrere Auswahlkriterien zur 
Verfügung: 

- Tage seit dem letzten Zugriff, 

- Zugriffshäufigkeit (bezogen auf einen bestimmten Zeitraun), 
- Dateigröte (-größenklassen). 

Durch Verknüpfung dieser Kriterien lassen sich noch weitere 
bilden. 


Das Simulationsprogramnm verarbeitet els Forderungsstron 
speziell aufbereitete SMF-Sätze der Typen 14 und 15, die im 
realen Produktionsbetrieb am ORZ der Humboldt-Universität 
erfaßt wurden. Dabei wurden nur Zugriffe zu solchen Dateien 
erfaßt, die potentiell im virtuellen Direktzugriffsspeicher 
lokalisiert sein können. 

Zur Auswertung der simulationsexperimente wird eine Druck- 
liste erzeugt, die für wichtige Modeilparameter Summen und 
Mittelwerte enthält. Für die weitere Auswertung werden in eine 
Ergebnisdatei ereignisorientierte Meßsätze ausgegeben. 
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Im Modellwerden ertaut: 

- Transportaufwand für Vateıen eınschlieslich der Zeiten für 
die Magnetbandpositionierung, 

- Arbeitslast des Systems, 

- Speicherauslastung und -fragmentierung, 

- wartezeiten in Einlagerungswarteschlangen. 


Im Simulationsmodell wird nicht berücksichtigt, dal das Ver- 
waLtungssystem des virtuellen DirektzugrırTfsspeichers selbst 
Ressourcen plockiert. Die Verwaltungsmaßnahmen und Datei- 
transporte haben auch keinen Einfluß auf den Forderungs- 

strom. Die berechneten Zeiten lassen qualitative Bewertungen des 
Verhaltens des virtuellen Direktzugriffsspeichers zu. 


3. Arbeitalast 

Es wurden die Dateizugriffe von 3556 Jobs innerhalb eines 
Zeitraumes von 54 Tagen erfaßt. In diesen Zeitraum wurde 
auf 434 potentiellen Dateien des virtuellen Direktzugriffs- 
speichers zugegriffen, die einen Speicherbedarf von 30 940 
Spuren haben. 

Eine tageweise Analyse ergibt folgende Werte: 


min max Mittelwert 
Dateien 1 103 | 61,3 
Spuren 100 10781 5789 


Tabelle 1 


wichtig für die Abschätzung des zu erwartenden Aufwandes 
durch die Verwaltungsmaßnahmen des virtuellen Direktzugriffs- 
speichers sind die Größen der tageweisen Änderung der Datei- 
zugriffe,. 


min max Mittelwert 
Dateien 1 .87 40,6 
Spuren 100 9551 3538 


Tabelle 2 
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4. Simulationsergebnisse 

In diesen Beitrag sollen lediglich Simulationsergebnisse be- 

züglich der Dimensionierung des virtuellen Direktzugriffs- 

spelchers und der Auslagerungsstrategie dargestellt werden. 

Für alle Simulationsexperimente werden folgende Parameter 

fixiert: i 

- die Datenträgerauswahl erfolgt nach dem Kriterium des 

größten Freibereiches, 

die Speicherplatzzuordnung erfolgt nach der Methode best- 

fit mit Extentbildung ohne Normierung der Dateigröße, 

- Einlagerungsanforderungen werden 3 Stunden gepuffert, 

die Dateisicherung erfolgt alle 3 Tage, spätestens 7 Tage 

nach der ersten Modifikation einer Datei, 

- die Magnetplatten des Primärspeichers sind von Typ 5061, 

- der Sekundärspeicher umfaßt 33 Magnetbänder mit einer Länge 
von 720 m (Typ 5017). 

Um Aussagen Über eine günstige Größe des Primärspeichers zu 

erhalten, wurde die Anzahl der Magnetplatten variiert. Wichtige 

Kennziffern sind in Tabelle 3 dargestellt. 


Einlagerung Auslagerung Gesamtauf- 
MP Dateien/ Spuren/ Dateien/ Spuren/ wand/Tag (h) 
Tag Tag Tag Tag 

1 53,5 5480 3,5 5509 2:01 

2 38,2 3671 37,7 3679 1233 

3 24,8 2075 25,1 2096 1:05 

4 14,7 1069 15,4 1121 0:41 

5 9,1 576 8,6 593 0:28 
Tabelle 73 


Wie zu erwarten, sinken die nötigen Aufwände mit steigender 
Größe des Primärspeichers. Interessant ist das Ergebnis eines 
Versuches, bei dem die Anzahl der Magnetbänder des Sekundär- 
speichers auf 70 erhöht wurde, deren Länge jedoch mit 350 m 
beträgt. Für 4 Magnetplatten sinkt der Gesamtaufwand auf 0:25 h. 
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Das zeigt, daß der Aufwand zum Suchen einer Datei in Sekundär- 
speicher, d.h. die Bandpositionierzeit, einen hohen Anteil en 
Gesamtaufwand hat. Bei.720 m langen Bändern und einer Band- 
geschwindigkeit von 2 m/s boträgt er oa. 80 %. 
Das Zugammenfassen von 3 Plattenstapeln zu einen entsprachend 
erößerem brachte eine Senkung des Aufwandes un 2 % durch 
verringerte Speicherfragmentierung. 
Für den Vergleich verschiedener Auslagerungsstrategien wurde 
ein Prinärspeicher mit drei Plattonstapeln festgelegt. 
Tabelle 4 zeigt Ergebnisse einer Versuchsreihe, 


Strate- Einlagerung Gesemntaufvand .max. Tagesauf- 

gie Dateien) spm au Teg (min) wand (min) ohne 
R z Reorg. 

1 = 2066 61 139 

2 20,3 2434 55 130 

3 22,1 2227 56 119 

4 22,9 1617 56 128 

5 17,4 2169 50 114 

6 20,9 1870 53 150. 

Tabelle 4 j 


Es warden folgende Strategien getestet: 

1 - Tage seit Letztem Zugriff 

2 = Tage seit letztem Zugriff = Größenklasse 

3 - (Tage seit Letztem Zugrifr)® x Größenklasse 

4 - 1/Zugrifrisnäufigkeit 

5 - Größenklasse/Zugrıffshäufigkeit 

6 - Tage seit letztem Zugriff = Größenklasse/Zugriffshäufigkeit 


Die Zugriffshäufigkeit wurde aus den Zugriffszahlen errechnet und 
zwar so, daß der jeweils letzte Zeitraum mit dem größten Ge- 
wicht eingeht. 


Die Wahl der Auslagerungsstrategie hat einen deutlichen Ein- 
fluß auf den Gesantaufwand, was in Differenzen von mehr als 
20 % zum Ausdruck kommt. Die Anzahl der bewegten Dateien be- 
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einflußt den Aufwand stärker als ihr Umfang. In dieser, wie 
auch in anderen Versuchsreihen ist die Strategie die beste, 
die von der Zugriffshäufigkeit bezogen auf Dateigröße aus- 
geht. 

Die Pufferung von Einlagerungsforderungen beeinflußt den 
Aufwand ebenfalls deutlich. Das Sammeln von Forderungen 
über jeweils sechs Stunden bringt gegenüber sofortiger 
Einlagerung einen um 20 % reduzierten Gesamtaufwand und 

10 % weniger Dateitransporte. 5 
In weiteren Versuchsreihen wurden unterschiedliche Kombi- 
nationen von Strategien getestet. Ferner wurde ein For- 
derungsstrom Über einen längeren Zeitraum mit höherer. 
Arbeitslast verwendet. Dabei zeigten sich in der Ten- 

denz die gleichen Ergebnisse. 


5. Schlußfolgerungen 
Aus den hier dargestellten und weiteren Simulationsergebnissen 
lansen sich folgende Schlußfolgerungen ziehen: 

- Der Aufwand für die Verwaltungsmaßnahnen des virtuellen. 
Direktzugriffeopeichers hängt wesentlich von den Bandsuch- 
zeiten bei der Einlagerung ab. 

- Das Puffern von Einlagerungsanforderungen senkt deutlich die 
Bandsuchzeiten. 

- Die Auslagerungsstrategie hat deutlichen Einfluß auf den 
Aufwand. Die Dateigröße muß bei der Bestimmung der Aus- 
lagerungsfolge berücksichtigt werden. 

- Best-fit mit Extentbildung (eine im OS/ES übliche Art der 
Speicherzuordnung) ist die günstigste Methode der Speicher- 
platzzuordnung, wenn ausschließlich der Aufwand des Ver- 
waltungssystems minimiert werden soll. Die Fragumentierung 
des Speichers muß näher. untersucht werden. 

- Sicherungsfristen unter 7 Tagen erhöhen deutlich den Auf- 
wand, die technologische Sinnfälligkeit ist auch nicht 
offensichtlich. 
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Iiteraturverreise: 
/1/ Kros, G.: "Rationalisierung der Arbeit eines Rechnersystens 
Qurch die Integration eines virtuellen Direktzu- 


griffaspeichers in das System SPOOL" (in diesen 
Heft) } 


‚Dipl.-Math. Conrad Piens 
Dipl.-NMath. Klemens Müller 
Humboiut-Universität zu Berlin 
Organisations- und Rechen- 
zentrum 
1086 Berlin, Unter den Linden 6 
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PEIMR B.M. 


CUCTEMA KOLIERTUEHOTO I0CTYIA 3EM MOCKOBCKOTO YHVBEPCHTETA 


B 000Ö0meHuH PaocMATpHBaeTorR CHOTEMA KOJLIEKTHBHOTO Noortyna IBM 
Km 0ÖecHeuekEH HAyGHHX uconenopammf u JuedHoTo Opoueoca. CHorte- 
Ma BRIKIAOT B O0da MuoILieiinyn 0e15 x paoıpenerteHHH6 TePMEFHATE- 
HNS OTAHIMH Ha Ödase MEHH-OEM. B 000ÖNEHHH OÖCYKTADTCH TAKE 
BOIPOOH PA3BETAH OXOTEMH KOJLISKTHBAOTO Kooryna 9M - IpEMeHeHHE 
OTAHTApTHOR MOINYIIEHOR Iporpamumpyemoß BNSKTPOHHKH H CDeIHe — 
NAOTOTHHX IEHHR OBASE JULI Nepenaum N OÖpadorku BKONEDHMEHTANGHHX 
TNAHHNX 0 HSMOPHTEIBHO-BHUHCJHTEJIEHHX KOMILIEKCOB. 
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Rieck, Klaus-Dieter 


Datei- und Datenträgerverwaltung mit dem System EDAS zur 
ESER-Datei-Archivierung und -Sicherung 


Das System EDAS dient speziell der Archivierung (Auslagerung) 
zeitweilig nicht benötigter Dateien, der Dateisicherung durch 
Nagnetbandduplikate sowie der Aktivierung (Bereitstellung) wie- 
der benötigter und der Rekonstruktion (Wiederherstellung) zer- 
störter Dateien. Dabei werden nicht, wie meistens üblich, perio- 
disch alle (auch die vielen nichtgeänderten) Dateien gesichert, 
sondern nur die vom Datei-Eigentümer (Nutzer) als notwendig ein- 
geschätzten. 


+ 


Speicherhierarchie: 
Die Dateien werden in einem mehrstufigen Speicherraum verwaltet. 


Stufe 1: Magnetplatten, auf denen die Jobs die Dateien ansprechen. 

Stufe 23 Magnetbänder zur Auslagerung der nichtaktiven Dateien; 
jeder Platte sind i. allg. mehrere Bänder zugeordnet. 

Stufe 3: Magnetbänder für die Sicherheitskopien aller Platten- 
dateien; sie werden im Zyklus chronologisch beschrieben, 
so daß jeweils ein Sicherheitsband aktuell ist. 

Die Magnetbänder werden von EDAS selbst verwaltet (der Nutzer 

muß nicht die Archivnummemkennen); sind alle Dateien katalogi- 

siert, kann auch die Zuweisung der Magnetplatten in Stufe 1 an 

EDAS übertragen werden. 


Katalogführung: 
Der EDAS-Katalog besteht aus dem Datenträger-, dem Nutzer- und 


dem Datei-Katalog; er enthält für jede Datei u. a. das Detum des 
letzten Zugriffs. Die Katalogdatelen werden doppelt, auf zwei 
Systemplatten, geführt; dadurch wird eine automatische Rekonstruk- 
tion bei Beschädigungen oder Systemplattenwechseln möglich. 


Kopiermodul: 
Alle Kopiervorgänge werden von einem universellen Modul ausge- 


führt, der automatisch die geeigneten 0S-Dienstprogramme aufruft, 
ohne daß der Nutzer Steuer- oder DD-Anweisungen angeben muß. 
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(Gegenwärtig verwaltet EDAS keine indexsequentiellen Dateien und 
keine Generationsgruppen. ) 


Kommandoprozessor: 
Die EDAS-Dienste werden i. allg. durch eine einfache EXEC-Anwei- 


sung ohne DD-Karten aktiviert (Aufruf einer Prozedur, in der alle 

Kommandoprogramma angesprochen werden können). Die wichtigsten 

EDAS-Funktionen: 

- Kopieren einzelner Datelaen zwischen Stufe 1 und 2 bzw. 1 und 
3 (copy) | 

- Dateivorbereitung (PREPARE) mit Aktualisierung des Zugriffs- 
datums und ggf. mit Bereitstellung von Stufe 2 nach 1 (reicht 
der Speicherplatz auf der Magnetplatte nicht aus, wird automa- 
tisch durch Auslagerung der am längsten nicht benutzten Dateien 
Platz gewonnen) 

- Archivieren (Auslagern nach Stufe 2) aller Dateien einer Mag- 
netplatte, auf die nach einem bestimmten Datum nicht mehr zu- 
gegriffen wurde (ARCHIVE) 

- Ausgabe von Verzeichnissen aller Dateien eines Datenträgers 
bzw. eines Nutzers (LIST) oder aller Datenträger (LISTVOL) 

- Ändern von Namen und Zuordnungen (CHNAME,CHANGE) 

- Verdichten von Magnetbändern (COMPRESS) 

- Aufnahme von Datenträgern, Nutzern und Dateien in die EDAS- 
Verwaltung (PVOL,PUSER,INSERT) 

- Entfernen aus der EDAS-Verwaltung (DVOL,DUSER, DELETE). 

Ein Teil der EDAS-Dienste kann auch Über eine TSO-Kommando- 
prozedur im Dialog aufgerufen werden. 
i i 

Ablaufsteuerung: 

Auf Wunsch können die für den Nutzer wichtigsten EDAS-Funktionen 

auch mittels einfacher Zusatzinformationen im Job (Kommentarkar- 

ten) ausgelöst werden. Für diesen Fall ist der Start eines spe- 
ziellen EDAS-Readers nötig. 


Gegenwärtige Anwendungen von EDAS; 
EDAS ist seit Anfang 1983 im Rechenzentrum der Hochschule für 


Verkehrswesen erfolgreich im Einsatz. Hauptanwendungsgebiet ist 
zur Zeit die Verwaltung von Testdateien in der Stapel- und Dia- 
logarbeit. 
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Dabei konnte durch Auslagerungen (alle 1-2 Monate) eine virtuelle 
Vergrößerung der Nagnetplattenkapazität um ca. 50 % erzielt we 
den. Außerdem wird EDAS zur Sicherung der Systemdateien benutzt; 
dadurch wird vermieden, daß vollständige Plattendumps hergestellt, 
werden, obwohl nur wenige Dateien geändert wurden. 


Begonnen wurde mit der Anwendung für das Projekt "Güterzugbil- 
dungsplanung", bei dem die einzelnen Teile des Streckennetzes 
durch eine Vielzahl von Dateien beschrieben werden, deren Ver 
waltung auf Magnetbändern manuell kaum zu bewältigen ist. 
Weitere Anwendungsmöglichkeiten: \ 

- Ökonomische Speicherung der Dateien an ESER-Arbeitsrechnern, 
die an entfernten Rechnern eines Netzes beheimatet sind, aber 
zeitweilig am Host verfügbar sein müssen 

- Sicherung von Dateien auf großen Nagnetplatten bei Vermeidung 
vollständiger Dumps 


Dr.-Ing. Klaus-Dieter Rieck, Hochschule für Verkehrswesen 
"Friedrich List", Rechenzentrum, 8010 Dresden, Friedrich-List- 
Platz 1 
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. HEIESHOB H.HO. ,PASYMOBA T.C.,OPOROB A.K. 
CPEICTBA COMPOBORIEHMA APXVBA HA MATHUTHNX HOCHTEILKK 


PaooMarpEBanTor BOLPOCH HERTPANASIOBAHHOTO BETEeHER AapXHBa 
Ha MATHETHHX HOCHTEJMX HK ABTOMATHSHPOBAHHOTO KOHTPOIM 3a 
O00TOAHHSM HOOHTENEN. 


Dr. Schreiber,Elke 0:2 


"Themas "Optimale Leistungsplanung im Rechenzentrumsbetrieb" 
Kurzvortrags 


Im Vortrag werden Mittel und Methoden der rechnergestützten 
optimalen Planung von Nutzeraufträgen der Massendatenverar- 
beitung vorgestellt. 

Ausgangspunkt ist die Bestimmung von Plandaten für spezifische 
Arbeitslasten Über ein implementiertes Moß-und Auswertesystem 
auf SMF-Basis. 

Als geeignete planungstechnische Einheiten fungieren soge- 
nennte Planungselemente,die eine Klassifizierung von Jobs nach 
spezifischen Kriterien darstellen. 

Im Programmsystem OPAL ist ein mathematisches Modell zur optims- 
len Ressourcennutzung und termintreuen Abarbeitung der Planungs- 
elemente implementiert. Kernstück dos Plenungsalgorithmus ist 
ein Branch-and-Bound-Algorithmus,über den sich die Optimierung 
vollzieht. u 

Im Ergebnis werden optimale Jobmixe und dazugehörige Jobcharak- 
teristika für die Ablaufsteuerung boreitgestellt. Steuervarian- 
ten moderner Betriebssysteme erfahren so eine notwendige Unter- 
stützung. 
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STUCHLIK, FRANZ; WINZERLING, WERNER 


AUTOMATISIERUNG DRS BETRIEBES VON EDVA UND BEDIENERLOSER BETRIEB 


1. EINLEITUNG 


Die Sitnation in den Reohenzentren der DDR ist z. 2. dadurch ge- 
kennzeichnet, daß ihrer verfügbaren EDVA-Kapazität ein wesentlich 
erdßerer Bedarf an Rechnerleistung gegenübersteht. /33/ /40/ 

Das führte in der Vergangenheit dazu, daß in der DDR vorrangig 
die Erhöhung der extensiven und intensiven Auslastung der Reohen- 
anlagen im .Mittelpunkt wissenschaftlicher Arbeiten und 
Veröffentlichungen stand. /3/ /23/ /31/ /L9/ /52/ 


Um die informationellen Prozesse bei der Durohsetzung der 
ökonomischen Strategie des X. Parteitages effektiv bewältigen zu 
‚können, wird die technische Basis der Rechenzentren, sowohl quan- 
er als auoh qualitativ weiterentwickelt. /24/ /33/ /40/ 


Mit diesen Veränderungen wird eine umfassende und durchgehende 
Automatisierung aller Prozesse des Rechenzentrums notwendig, um 
auch bei größerer Rechnerkapazität und komplizierter werdender 
Ablauforganisation eine hohe Effektivität zu gewährleisten, öhne 
gleichzeitig den Personalbestand zu erhöhen. 

Ein Übergang zu bedienerarmen Formen des Betriebes von Rechenan- 
lagen wird dabei unumgänglich. 


Während in der internationalen Literatur bereits über Forschungen 
zum Problemkreis "zeitweilig unbedient betriebene EDVA" berichtet 
wurde (/5/, /6/, /11/, /12/, /43/, /15/,: /16/, 1171, /18/, /20/ 
/aA/, /297, /33/, 739, /53/, 754/) findet diese Betriebsform in 
den Publikationen der DDR bisher kaum Beachtung, /23/ bzw. wird 
sie als ungeeignete Zielstellung für die Rechenzentruns- 
Automatisierung in der DDR abgelehnt (/31, S. 90/). 


2. AUTOMATISIERUNGSTENDENZEN BEI MITTLEREN UND GROSSEN EDVA 


Bei den Veränderungen auf dem Gebiet der Informatik wird allge- 

mein davon ausgegangen, daß im Perspektivplanzeitraum Reohenzen- 

tren mit mittleren und großen EDVA ihre Bedeutung behalten, wenn 

ans a einem veränderten Aufgabenspektrum. /10/ /36/ /40/ /u4/ 
5 51 


Im folgenden werden einige Entwicklungen und ihre Auswirkungen 
auf die Automatisierung des Rechenbetriebes diskutiert. /10/ /15/ 
zı7/ leu/ 1/26/ /28/ /31/ /32/ /34/ /36/ /39/ /40/ /u1/ /12/ /u3/ 
/uu/ /45/ /46/ /48/ /49/ /51/ 
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(1) Steigende Leistungsfähigkeit der EDVA 


Die steigende Leistungsfähigkeit der EDVYA (höhere Operations- 
geschwindigkeiten, größere und sohnellere Hauptspeicher, sohnel- 
lere Systenspeioher u. a.) /24/ /43/ vergrößert den möglichen 
Jobdurchsats, und erhöht seine Komplexität. 

Damit wird nur ein automatisierter Betrieb der Rechenzentren eine 
intensive Auslastung der Reohnerressouroen gewährleisten. 


(2) Direkte Jobeingabe in die EDVA duroh Stapelfernverarbeitung 


Mit der Vergrößerung der Anzahl der Stapelfernverarbeitungs- und 
Dialogterminals, und. entspreohender Steuerprogramme erlangt die 
Dialogatapelfernverarbeitung, z. B. in wissenscohaftlichen und 
HORDBOUNISRUORSEBANERER der DDR, eine zunehmende Bedeutung /28/ 
Zur Kontrolle und Einplanung der ferneingegebenen Jobs für die 
Stapelverarbeitung müssen automatisierte Lösungen angewendet wer- 
den, da diese Jobs nicht mehr als Loohkartenstapel die Arbeits- 
vorbereitung durohlaufen. 


6) Kochnernetue 


Reohnernetze ermöglichen z. B. eine zunehmende Spezialisierung 
der angesohlossenen Reohenzentren /24/ /26/ /u8/. 

Auch hier durohlaufen die ferneingegebenen Aufträge nicht mehr 
die Arbeitsvorbereitung des Zielreohners. Die Kontrolle der 
Hutzungs- und Zugriffsbereohtigung und die Einplanung zur Ver- 
arbeitung bedürfen automatisierter Lösungen. wi 


(4) Speicherung und Verwaltung von Dateien 


Die Entwioklung bei Direktzugriffsspeichern für mittlere und 
große EDVA führt zu Festplattenspeicher-Geräten mit Kapazitäten 
von mehreren GByte je Plattenstapel /1/ /5/. 

Es wird davon ausgegangen, daß künftig leistungsfähige EDVA über 
ein Speichersystem mit 5 - 6 Hierachilestufen verfügen; vom 
sohnellen Caohe-Pufferspeicher, über den Hauptspeicher, den Plat- 
tenspeichern, einem Massenspeicher, bis zur letzten Hierachie- 
stufe, dem Magnetbandarchiv. /42/ 

Für die Verwaltung der verschiedenen Speichermedien werden zuneh- 
mend - besonders in wissensohaftliohen und Hoohschul- 
Reohenzentren — automatisierte DateiverWwaltungssysteme eingesetzt 
/9/ /319/. Dabei erfordert nur die letzte Hierachilestufe inner-. 
halb des Speichersystens — das Magnetbandarchiv — künftig noch 
eine Bedienung duroh Operator /34/ /39/. 


Das erste international verbreitete automatisierte Datelverwal- 
tungssystem war der, im Betriebssystem GEORGE 3 integrierte, 
Datei-Speicher (GEORGE 3 Filestore) für ICL-Reohner. /4/ 

In der DDR ist die Entwioklung eines Dateiverwaltungssystens 
z. B. innerhalb des Systems SPOOL ab Version 3, als Konzept eines 
virtuellen Direktzugriffsspeicohers vorgesehen. /34/ 
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(5) Benutzergesteuerte Datenein- und -ausgabe 


Die erwähnten Entwicklungen auf dem Gebiet der Nachriohten- 
übertragung, sowie der Mikrorechenteohnik (z. B. lokale Netze) 
ermöglichen den Nutzern den dezentralen Zugriff zu zentralen 
Rechnerressourcen /24/ /40/ /18/ /51/.: 

Dabei werden zunehmend die Ein- / Ausgabeprozesse zur Jobeingabe 
und Ergebnisausgabe nicht mehr im Rechenzentrum ausgeführt, son- 
dern direkt am Arbeitsplatz des Nutzers (oder in dessen unmittel- 
barer Nähe) und unter seiner Steuerung. 


Wird Spezialperipherie (z. B. Plotter u. &) auch dezentral aufge- 
stellt und durch die Nutzer bedient, können in der Praxis auftre- 
tende Sonderfälle der Ein- / Ausgabe vom Nutzer behandelt werden. 
Damit ist es möglich, schwer zu automatisierende bzw. selten auf- 
tretende, Bedienhandlungen an speziellen peripheren Geräten, aus | 
dem Reahenzentrum herauszunehmen und an die Nutzer zu übergeben, 


Die geringfügige Erhöhung des Arbeitsaufwandes beim Nutzer, kann 

1. d..R. jedoch vernachlässigt werden, da 

- die Datenerfassung in einem wissenschaftliohen bzw. Hoohschul- 
Rechenzentrum meistens vom Nutzer selbst durohgeführt wird, und 

‘= sioh hierbei für den Nutzer die Durchlaufzeit seiner Aufträge 
duroh das Rechenzentrum verkürzt. 


(6) Zuverlässigkeit künftiger EDVA und Unterstützung der Rechen- 
zentrums-Organisation 


Mit dem Einsatz hoohintegrierter Bauelemente und der Weiterent- 

wicklung der Arohitektur von Reohenanlagen und ihrer Ressourcen- 

verwaltung steigt auch deren Zuverlässigkeit /1/ /24/ /u3/. 

Künftige Betriebssysteme werden in zunehmendem Maße die gesaute 

Bas eunenteuna Ozean laaklen unterstützen /15/ /31/ /41/ /hh/ 
9 . \ ö 


3. UNBEDIENTER BETRIEB VON EDVA IN RECHENZENTREN 


Der Betrieb von EDVA für Stapelverarbeitung erfordert eine 
manuelle Bedienung. 

Es gibt jedoch Perioden, in denen wenige oder keine Bedienhand- 
lungen erforderlich sind. Durch technologisohe Maßnahmen ist es 
möglich längere Zeitabschnitte "ohne Bedieneingriffe" zu sohal- 
fen. j 
Aus der Literatur. sind eine Reihe von Rechenzentren bekannt, die 
naoh diesem Prinzip Stapel-EDVA die Naohtsohicht bzw. das gesamte 
Wochenende ohne Anwesenheit von Operatoren betreiben. /5/ /6/ /9/ 
/12/ /16/ /17/ /18/ /20/ /21/ /23/ /297 /32/ /39/ /53/ /55/ 
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3.1. Unbedienter Betrieb von Stapel-EDVA In der DDR 


Eine erste Variante eines bedienerarmen Betriebes von EDVA in der 
DDR publizierte 1982 das Rechenzentrum der Humboldt-Universität 
zu Berlin /23/. 

Als Gründe für das bisher nur geringe Interesse an einer unbe- 
dienten Betriebsweise von Stapel-EDVA (/31, S.. 90/) werden u. 2 
gesehen: 


4) Im Unterschied zu anderen Ländern wurde in der DDR der "Be- 
diener einer EDVA" schon frühzeitig ein Ausbildungsberuf. Da- 
-durch, und durch staatliche Lenkungsmaßnahmen standen bisher 
immmer gentigend ausgebildete Operator zur Verfügung, während 
in anderen Ländern der Mangel an ausgebildeten Operatoren zum 
bedienerarmen bzw. unbedienten Betrieb der EDVA zwang. (vel. 
/27, S. 2/ mit /16/, /22/, /29/) 


(2) Aufgrund der Hardware-Kostenstruktur, sowie der Produktions- 
fondsabgaben ist ‚der Anteil der Lohnkosten im Verhältnis zu 
den Hardwarekosten in der DDR geringer als in den Ländern, 

. aus denen bedienerlos betriebene Stapel-EDVA bekannt geworden 
sind /12/ /16/. 


(3) Eine Störung während des unbedienten Betriebes - wie z. B. 
ein Betriebssystemabsturz - kann zu erhebliohen Produktions- 
ausfällen führen, weil 1. d. R. bisher kein automatischer 
en einer unbedient ‘betriebenen EDVA möglich ist /5/ 

11 
Eine hohe Auslastung der Anlagen kann daduroh gefährdet wer- 
den. 


(4) Während des unbedienten Betriebes muß die Kommunikation zwi- 
schen "Operator" und Betriebssystem automatisiert werden. 
EEE steht das System SPOOL 2.0 seit 1982 zur Verfügung 

23 . " 


(5) Ein unbedienter Betrieb einer EDVA erfordert ' eine hohe 

Systemverfügbarkeit und Zuverlässigkeit, um die Ausfallzeiten 
gering zu halten (siehe auch Punkt 3).. 
In /14/, /3/ und /47/ werden Untersuchungen zur 
Störsicherheit von EDVA des ESER durchgeführt. Dort wird aus- 
gewiesen, daß aufgrund von Störungen in der Gerätetechnik, 
sowie aufgrund von Mängeln in der Technologie des Rechen- 
zentrums durchschnittlich 5,2 -— 18 IPL's innerhalb von 
24 Stunden Nutzzeit notwendig waren. 


(6) Die Kapazität an Direktzugriffsspeichern - wie sie in den 
vielen Reohenzentren der DDR i. d. R. anzutreffen ist (/1/ 
/5/ /8/ /21/ /30/) - führt zu einer erhöhten Anzahl manueller 
Montierhandlungen. Dadurch werden die Abschnitte begrenzt, in 
denen ein unbedienter Betrieb der : EDVA - ohne Montierhand- 
lungen en Direktzugriffsspeichergeräten - möglich ist /23/. 
Große Speiocherkapazitäten auf Direktzugriffsspeichern sind 
eine notwendige Voraussetzung für eine Erhöhung der 
Effektivität und die Automatisierung des Betriebes von EDVA. 
/11/ /21/ /31/ /39/ /49/ /51/ 
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3.2. Klassifizierung des unbedienten Betriebes 


3.2.1. Klassifizierung nach der notwendigen Bedienung. 


‚Im folgenden wird der Betrieb einer EDVA nach dem Umfang der 
notwendigen Bedienung _ klassifiziert, ohne auf die "derzeitige 
Praxis" (im Bild 1 als "normaler bedienter Betrieb" bezeichnet) 
/31/ /38/ /50/ näher einzugehen. 


Formen der Bedienun einer EDVA 
- r 


bedienter Betrieb unbedienter Betrieb 
"normaler" bedienerarmer zeitweilig vollständig 
operatorlos operatorlos 


Bild 1: Klassifizierung nach dem Umfang der Bedienung einer EDVA 


Bedienerarmer Betrieb einer EDVA 


Durch Automatisierungsmaßnahmen können. ‚während des Betriebes 
einer EDVYA Zeitabsohnitte geschaffen werden, :' in denen keine 
Bedienereingriffe notwendig sind. SE: 
In praktischen Lösungen - arbeitet hier die _Zentraleinheit 
ausschließlich mit vormontierten magnetischen Datenträgern. Der 
Jobstrom und die Verarbeitungsergebnisse werden auf einem magne- 
tischen Datenträger zwischengespeichert -— "gespoolt" /12/./23/. 
Bedienereingriffe sind nur nach einem Betriebssystem-Absturz 
notwendig, um den Neustart des Betriebssystens vorzunehmen. 

Bei einer hinreichend hohen Systemverfügbarkeit der EDVA kann die 
Arbeit der EDVA auoh ohne Anwesenheit eines Operators erfolgen. 
Der zeitweilige Betrieb einer EDVA ohne Anwesenheit eines Opera- 
tors, (jedooh auch ohne die Möglichkeit eines automatischen 
Wiederstarts der EDVA nach einen Betriebssystem-Absturz) wird im 
folgenden als die 


"konsequenteste Form des bedienerarmen Betriebes" 


einer EDVA bezeichnet. 


‚zeitweilig operatorloser Betrieb einer EDVA 


Die weitere Automätisierung der Bedienung einer EDVA führt von 
einem bedienerarmen Betrieb zum zeitweilig operatorlosen Betrieb. 
‚Der Untersohied zur konsequentesten Form des bedienerarmen 
Betriebes ist die "Möglichkeit des automatischen Wiederanlaufes 
ainer EDVA nach einem Betriebssystem-Absturz, und die daduroh 
erreiohbare größere Systemverfügbarkeit. 

Auch hier werden duroh technologische Maßnahmen die. Zeitabsohnit- 
te geschaffen, in denen die Zentraleinheit aussohließlich mit 
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vormontierten Datenträgern arbeitet. 


Vollständig operatorloser Betrieb einer EDVA 


Beim vallst4ndig operatorlosen Betrieb einer EDVA wird der - ohne 
‚Angesenheit eines Operators durohgeführte - Betrieb nicht mehr 
‚von bedienten Arbeitsabsohnitten abgelöst. Duroh die Operator 
wird nur noch. eine "Wartung" der EDVA durchgeführt, bei der z. B. 
die Druoker neu mit Druckpapier besohlokt werden. 


Der vollständig operatorlose Betrieb "natzt eine weitestgehende 

‚Automatisierung bzw. Substitulierung der manuellen Prozesse bei 

der Bedienung der EDVA voraus, wie z. B. 

‚= operatorlos betriebene Peripherie, 

- qualitativ. höheres Niveau der Steuerungsalgorithnen der Be- 
‚.triühanysteme,.. die keine . Eingriffe des Operators mehr erfor- 

ern, 

- Übertragung manueller Bedienhandlungen der Operator an die 

Nutzer. 


3.2.2. Klassifizierung nach der notwendigen Beaufsichtigung 


Eine weitere Klassifizierung des Betriebes einer EDVA erfolgt 
nach der notwendigen Beaufnichtigung. . 


Beobaohteter Betrieb 


Der Betrieb der EDVA erfordert hier eine ständige Aufsicht. Das 
ist die 2. Z. übliche Form des Betriebes einer EDVA in der DDR 
/35/ /38/. 

Um jedooh die Wahrscheinlichkeit der Früherkennung eines Soha- 
densereignrisses .zu erhöhen, wird oftmals duroh teohnische 
Sioherheitsmaßnahmen eine zusätzliche automatische Überwachung 
der BDVA und ihres Umfeldes gewährleistet. Das betrifft in der 
Regel nur einzelne mögliche Schadensereignisse, mit einem hohen 
Sohadensrisiko, wie z. B. die Früherkennung eines Brandes. 


Unbeobaohteter Betrieb mit Kontrollen 


Werden durch technische Sicherheitseinrichtungen alle wahrschein- 
lichen Scohadensereignisse eines Reochenzentrums überwaoht, und- 
wird dabei die gleiche bzw. eine höhere Sicherheit erreicht, wie 
bei einer Beobachtung durch das Bedienpersonal, dann kann die 
EDVA auch unbeobachtet betrieben werden. 


Um nicht für jedes mögliche Schadensereignis aufwendige teohni- 
sche Überwachungseinrichtungen für den unbeobachteten Betrieb 
installieren zu müßen, kann folgende Lösung gewählt werden; 


(1) Installlierung von technischen Überwachungseinrichtungen zur 
Erkennung von Sohadensereignissen, die kurzfristig und mit 
relativ hoher Wahrscheinliohkeit auftreten können. Z. B.: 

- Brand, 
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Klimastörung, 
Geräteausfall, 
Wasserschaden, 
Einbruch. 


(2) Das Auftreten weniger wahrscheinlicher Scohadensereignisse mit 
größerer Auftritts-Wirkungs-Zeitdauer wird duroh regelmäßige 
Kontrollen, der sonst unbeobachtet betriebenen EDVA 
überwacht. 


Vollständig unbeobaohteter Betrieb 


Der Betrieb der EDVA erfolgt hier völlig unbeobaohtet und nur 
durch technische Sicherheitseinrichtungen (automatische Feuer- 
löschanlage, Einbruchsüberwachung u. a.) überwaoht. i 

Eine solche Betriebsweise wird vorerst nur in speziellen 
Anwendungsfällen möglich sein (z. B. unbedienter und unbeobachte- 
ter Betrieb eines Knotenrechners in einem Reohnernetg). 

Für Stapel-EDVA ist eine solche Betriebsweise nooh nicht wirt- 
schaftlich realisierbar. 


4. REALISIERUNG DES UNBEDIENTEN BETRIEBES EINER. ESER-EDVA 


Die Durchführung des unbedienten Betriebes einer EDVA erfordert 
eine Automatisierung, Substitulerung, sowie die räumliche und 
zeitliche Verlagerung der bisher notwendigen manuellen Bedien- 
handlungen. 

Problematisch dabei ist, daß EDVA heute - auch international - 
noch nioht ausreichend für einen unbedienten Betrieb ausgelegt 
sind /5/ /11/ /12/ /55/. 


4.1. Problemstellungen des unbedienten Betriebes 


Bei der Realisierung des unbedienten Betriebes einer ESER-EDVA 
müssen Lösungen folgender fünf zentraler Problemstellungen go- 
funden werden: 


(1) Das Betriebssystem 0S/BS unterstützt nicht‘ den unbedienten 
Betrieb einer ESER-EDVA. 

(2) Nach einem Betriebssystem-Absturz kann ein Betriebssystem- 
neustart (IPL) einer ESER-EDVA nur durch einen Bediener 
erfolgen. 

(3) Die Peripherie einer ESER-EDVA ist für die Bedienung durch 
Operator vorgesehen. 

(4) Die Technologie des Rechenzentrums ist 1. d. R. auf einen be- 
dienten Betrieb ausgerichtet. " 

(5) Alle sioherheitsteohnischen Überwachungen sind für Mit- 
wirkungen der Operator ausgelegt. ! 
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4.2. Lösung der Problemstellungen des unbedienten Betriebes 


Im folgenden werden mögliche Lösungen der o. g. Problemstellungen 
vorgeschlagen. Dabei soll ein zeitweilig operatorloser und un- 
beobachteter Betrieb einer ESER-EDVA (mit Kontrollen) (vgl. 3.2.) 
den Vorschlägen zugrunde liegen. 


(1) Automatisierung der Könsolbedienung 


Während des unbedienten Betriebes mıß das Konsolinterfaoe zwi- 
schen Betriebssystem und Operator automatisch bedient werden. 

Be existiert mit dem System SPOOL ab Version 2.0 eine Lösung 
23/. 


(2) Automatischer Wiederanlauf 


Ein Problem des unbedienten Betriebes ist die Gefahr eines 
Systemabsturzes. Nach einem Absturz des Betriebssystems mıß ein 
automatischer Neustart durohgeführt werden. Ist aufgrund eines 
schwerwiegenden und nicht automatisoh korrigierbaren Fehlers ein 
Neustart des Systems nicht möglich, muß ein Re TSRAr im Bereit- 
schaftsdienst darüber informiert werden. 


(3) Arbeit mit der Peripherie während des unbedienten Betriebes 


Während des unbedienten Betriebes arbeitet die Zentraleinheit nur 
mit vormontierten Magnetplatten. Auf die gewohnte Ein- / Ausgabe 
wird während dieser Zeit verzichtet. /11/ /12/ /23/ 

Die Jobstromeingabe (z. B. Über Lochkarten oder Lochstreifen 
u. a.) muß vor dem unbedienten Betrieb und die Ergebnisausgabe 
(Drucklisten, Lochkartenausgabe u. a.) kann erst nach dem unbe- 
dienten Betrieb durohgeführt werden. 


(#4): Teohnologische Einbindung des unbedienten Betriebes 


Für die technologische Einbindung des unbedienten Betriebes in 
die Rechenzentruns-Organisation ist der Umfang und die konkrete 
Form des unbedienten Betriebes, sowie die Qualität der bisherigen 
Reohengentrums-Technologie bestimmend. 

Sohwerpunkte sind abhängig vom konkreten Rechenzentrum. /9/ /11/ 
/12/ /16/ /18/ /21/ /23/ /29/ /32/ /39/ /55/ 


(5) Sioherheitstechnische Überwaohung der unbeobaohteten BDVA- 


Die Ablehnung des unbeobaohteten Betriebes einer EDVA erfolgt 
oftmals aus sioherheitsteohniscohen Überlegungen /35/. 

Soll eine EDVA unbeobaohtet betrieben werden, müssen höhere An- 
forderungen an die Überwaohungseinriohtungen gestellt werden, als 
sie für einen bsobaohteten Betrieb notwendig sind. 


Bei der Erarbeitung eines Sioherkeitskonzeptes für den unbeobach- 
teten Betrieb sind vorrangig die Risiken zu beaohten, die bisher 
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durch die Anwesenheit von Kontrollpersonen ausgeschlossen wurden. 
Das betrifft vor allem die Risiken: 
- Brand, 
Klimastörung, - 
Wasserschaden, - 
Einbruch (Spionage, Rowdytum u. a.). 


Außerdem sind die örtlichen Gegebenheiten und das Nutzungsprofil 

während des unbeobachteten Betriebes zu berlioksiohtigen. Das be- 

trifft vor allem die Gegebenheiten: 

- Lage des Recohenzentrums’ und dadurch ausgeschlossene bzw. daraus. 
resultierende Risiken; 

- bereits vorhandene Sicherheitsvorkehrungen und -einriohtungen;, 

Vertraullchkeitsgrad der bearbeiteten Daten; ur 

Möglichkeit von regelmäßigen Kontrollgängen während des un- 

beobaohteten Betriebes der EDVA. 

/2/ /11/ /12/ /13/ /20/ /25/ /35/ 


5. ENTWICKLUNGSTENDENZEN BEIM BEDIBNERARMEN BZW. UNBEDIENTEN 
BETRIEB 


5.1. Realisierte Lösungen 


Im' folgenden werden zwei Fälle vorgestellt, bei denen die konse- 
quenteste Form des bedienerarmen Betriebes bzw. der unbediente 
Betrieb einer EDVA realisiert wird. 


5.1.1. Konsequenteste Form des bedienerarmen Betriebes 


. (unbeobachtet mit Kontrollen) 


In Zentrum für Datenverarbeitung der Universität Tübingen arbei- 
ten zwei zentrale EDVA während der Nachtschicht und während des 
Wochenendes ohne Operator — d. h. unbeobachtet mit Kontrollen, in 
der konsequentesten Form des bedienerarmen Betriebes. /12/ 


Die hohe Verfügbarkeit der EDVA und sicherheitstechnisohe Über- 
waohungseinrichtungen (Klimaüberwachung, Brandmelder mit automa-- 
tischer Feuerlöschanlage und automatischer Alarmierung der Feuer- 
wehr) ermöglichen den unbeobachteten Betrieb mit Kontrollen. 
Dabei werden zur Kontrolle der EBVA auch die Nutzer hinzugezogen, 
die durch eine Glasscheibe aus der Expreßstation in die Reohner- 
rdume sehen können. Sie sind . aufgefordert, bei erkannten 
Unregelmäßigkeiten telefonisch einen diensthabenden Operator zu . 
benachriohtigen. 

Man verläßt sich hier auf die fast lüokenlose Kontrolle der EDVA 
durch die Benutzer der Expreßstation auch in den Nachtstunden und 
am Wochenende /12, S. 17/. 

Bei einem Betriebssystem-Absturz wird ein längerer Stillstand der 
EDVA akzeptiert, da ein automatischer Wiederanlauf der EDVA nioht 
vorgesehen ist. Jedoch tritt aufgrund einer hohen Systenver- 
SUBBENLeLE nur selten ein Ausfall der EDVA ein /12, S. 21/. 
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5.1.2. Zeitweilig bis vollständig operatorloser Betrieb 
(unbeobachtet mit Kontrollen) 
Eine zukunftsweisende Forn des unbedienten Betriebes einer EDVA 


wre in /47/ aus japanisohen Hochscohul-Rechenzentren berichtet. 
uro 


- Übertragung von Arbeiten, die bisher von Operateuren aus- 
geführt wurden, auf die Benutzer 

- Automation im Maschinensaal durch Wegfall bisher. nanuell zu 
verriohtender Arbeiten 

- Automatisierung im Steuerungsablauf der DV-Systeme" 
17, Ss. 137/ 


warde. in . einigen japanisohen Hoohschul-Rechenzentren ‘ ein 
vollständig operatorloser Betrieb realisiert. 


Über den Umfang der notwendigen Beobachtung der EDVA wurden in 
/17/ keine Aussagen gemacht. 


Als entscheidende Voraussetzung für die operatorlose Betriebs- 
weise in den beschriebenen japanischen Hochschul-Reohenzentren 
wird die großzügige Geräteausstattung genannt, vor allen hin- 
sichtlich 


- einer großen Direktzugriffs-Speioherkapazität aus unbedient be- 
triebenen Plattengeräten bzw. Massenspeiohersystemen für die 
* Zwisohenspeioherung des Jobstromes und aller Druokausgabe- 
dateien bis zu ihrem Abruf duroh die Nutzer (Spooling), 
* für die Aufnahme aller Nutzerdateien /17, S. 138, 140/. 


Weiterhin steht in Expreßstationen der beschriebenen japanisohen 
Hoohsohul-Reohenzentren eine große Zahl von Loohkartenlesern bzw. 
Bildsohirnterminals für die Jobstromeingabe, sowie von 
Hagnetbandgeräten (die vom Benutzer selbst bedient werden) zur 
Verfügung /17, S. 138, 139/. 


Die Überlegungen zur Nealisierung eines bedienerarmen bzw. unbe- 
dienten Betriebes in Reohenzentren der DDR müssen von anderen, 
als den in /17/ genannten, Hardware-Voraussetzungen ausgehen. 


5.2. Internationale Entwioklungstendenzen 


In (2.) wurden bereits internationale Entwicklungstendenzen be- 
sobrieben, die zukünftig eine zunehmende Automatisierung der 
Rechenzentrums-Funktionen - auch der Maschinenbedienung - er- 
möglichen und erfordern werden. 

Außerdem 148t sich international auch ein großes Interesse der 
Reohenzentrum-Betreiber an einem bedienerarmen bzw. zeitweilig 
operatorlosen Betrieb der genutzten EDVA erkennen. So wird in 
/5/, /12/, /39/, /44/ von künftigen EDVA eine bessere Hardware- 
und Software-Unterstützung der unbedienten Betriebsweise sefor- 
dert. (siehe auoh 2. Punkt 6) 


Erste Tendenzen hierzu sind bei den Computerherstellern bereits 
zu erkennen. ” 


6-70 


So ist z. B. das neue UNIVAC 1100/90 - System mit einem Servioe- 
Prozessor ausgerüstet, der als dedizierter Minioomputer die 
folgenden Aufgaben hat (/1, S. 63 - 64/): 


- Hardwareüberwachung der zentralen EDVA (mit der Fähigkeit der 
Wiederherstellung oder Abschaltung von fehlerhaften Systenkon- 
ponenten 

- Initialisierung des gesamten Systems (Initialisierung der Ein- 
zelkomponenten und IPL-Ladevorgang 

- Unterstützung von Wartungsaktivitäten. 


In /15/ wird z. B, über Aktivitäten des Computerherstellers IBM 
berichtet, die zum Ziel haben, alle Rechner eines Reohnerve=- 
bundes, ausschließlioh von einer zentralen Stelle aus steuern zu 
können. Dazu wurde ein Überwachungsreohner implementiert, "indem 
die Systemmeldungen aller betriebenen Rechner konzentriert und 
interpretiert werden und der alle Kommandos für die einzelnen 
Rechner weitervermittelt ..." /15, S. 197 -— 198/. 


6. LITERATURVERZEICHNIS 


/1/ Adler, Hans-Joachim 
a von :Großrechnern - Beispiel SPERRY UNIVAC 
1100/90 
in: Handbuch der modernen Datenverarbeitung HDM; 
Forkel-Verlag Stuttgart-Wiesbaden 19(1982) Heft 107 
September, S. 59 - 66 


/2/. Allianz Versicherungs-AG (Hrsg. ) 
Handbuch der Sohadensverhütung 
3.1. Elektronische Datenverarbeitung (EDV-Anlagen) 
in: Handbuoh der Schadensverhütung 2., erweiterte und 
überarbeitete Auflage, Allianz Versicherungs-AG 
München, Berlin(West) 1976, S. 121 — 139 


/3/ PBergholz, Gerhard - 
Leistungsbewertung im Rechenbetrieb 
in: Rechenteohnik Datenverarbeitung Berlin 21(1984) Heft' 1, 
5. 10 — 13 


/4/  Cuttle, G.; Robinson, P. B. 
Executive programns and operating systens 
Mac Donald London and American Elsevier Inc. New York 1970 


/5/ Dirlewanger, W. 

Integration von Funktionen betrieblicher Rechenzentren in 

den technisch — wissenschaftlichen Rechenbetrieb 

in: Organisation und Betrieb ’von Rechenzentren, 
Fachgespräch der GI, Erlangen, 12./13. März 1981, In- 
formatik Fachberichte Band 46, Brauer, W. (Hrsg.) 
Springer-Verlag Berlin(West), Heidelberg, New York 
1981, S. 116 - 129 


/6/ 


/U 


/8/ 


/9/ 


719/ 


/12/ 


713/ 


z14/ 


6-71 
Dücerkop, Klaus 
Ablaufplanung im RZ der ARAL AG - Anwendererfahrungen mit 
OPC 
in: Ablaufplanung und Arbeitsvorbereitung im Rechenzentrum 
Fachseminar Universität Köln, 7./8. Februar 1980 im 
‘Helfta-Seminar, Seibt, Dietrich (Hrsg.), Köln 1980, 
3. Kapitel 


Faltenbaoh, Hans 

Methoden und Verfahren zur Steuerung von Großrechenzentren 

Teil 1 und Teil 2 - 

An: IBM-Naohrichten Stuttgart 28(1978) Heft 243, 
Ss. 356 - 361; 29(1979) Heft 244, S. 36 — 44 


Gaffal, Franz 

Datenverarbeitung im Hochschulbereich der USA -— Stand und 
Entwioklungstendenzen 

Informatik Fachberichte Band 26, Springer-Verlag 
Berlin(West), Heidelberg, New York 19B0 


Graef, Martin (Hrsg. ) 


Benutzerleitfaden - Zentrum für Datenverarbeitung der 
Universität Tübingen Ausgabe: Oktober 1981 

Universität Tübingen, Zentrum für Datenverarbeitung, 
Tübingen 1981 


Graef, Martin 

Das Reohenzentrum-Personal der Zukunft 

in: Betrieb von DV-Systemen in der Zukunft, 
5. GI-Faohgespräche über Rechenzentren, Tübingen, 
17./18. März 1983; Graef, Martin (Hrsg.), Informatik 
Faohberiohte Band 69; Springer-Verlag Berlin(West), 
Heidelberg u. a. 1983, S. 334 — 341 


Graef, Hartin; Greiller, Reinald 

Organisation und Betrieb eines Rechenzentruns 
Schriftenreihe Integrierte Datenverarbeitung in der Praxis 
Band 13, 2., überarbeitete Auflage; Forkel-Verlag Stutt- 
gart, Wiesbaden 1982 


Graef, Martin; Maier, Bdgar 


‚Erfahrungen über operateurlose RZ-Schiohten 
inı Das Reohenzentrum München, Wien 6(1983) Heft 1, 


S. 415 - 23 


Höfling, Bernd; Zwingert, Gerd 

Sicherheit im Reohenzentrum 

An: Handbuch der modernen Datenverarbeitung ADM; 
Forkel-Verlag Wiesbaden, Stuttgart 19(1982) Oktober 
Lieferung 103a 9/4/37, Blatt 1 — 24 


Hofmann, Hans-Christoph 

Untersuohungen der Dialogwürdigkeit für die Kontrolle und 
Lenkung der Produktion am Beispiel des VEB DVZ Halle 
Diplomarbeit, Ingenieurhoohschule Dresden, Sektion Informa- 
tionsverarbeitung; Dresden 1980 


715/ 


/16/ 


U 


/18/ 


U 


/20/ 


721/ 


/22/ 


6-72 


Hultzsch, Hagen 

SEAS, SHARE, EUROPEAN ASSOCIATION Bericht vom Spring Meeting 

1982 in Noordwijkerhout/Holland 

in: Das Boah enaonbaea München, Wien 5(1982) Heft 3, 
Ss. 195 — 19 e 


Jasper, Erich 
Arbeitsvorbereitung als Möglichkeit zur Steigerung der 
Effizienz des Hochschulrechenzentrums 
in: Organisation von Rechenzentren (Workshop der Gesell- 
“ schaft für Informatik, Göttingen 11./12. Oktober 1977) 
Informatik Faohberichte Band 15 Springer-Verlag 
Berlin(West), Heidelberg, New York 1978, S. 13 -— 22 


Jasper, Erich 

Organisation und Betrieb japanischer Hochschulrechenzentren 
Teilaspekt: Operateurloser Betrieb 

in: Das Ben en onEzun Münohen, Wien 5(1982) Heft 3, 


Jochum, Hans-Günter 

Probleme und Realisierung eines unbedienten Rechenzentruns- 

Betriebes 

in: Betrieb von DV-Systenen -1in der Zukunft, 
5. GI-Faochgespräche über Rechengentren, Tübingen, 
17./18. März 1983; Graef, Martin (Hrsg.), Informatik 
Fachbericohte Band 69 Springer-Verlag Berlin(West), Hei- 
delberg u. a. 1983, S. 51 - 60 


Kießling, Helge 

Hethoden und Techniken der Organisation eines Reohenzem 
trunms 

in: Datascope Sulzbach/Taunus 10(1979) Heft 29, S. 9 - 22 


Knauer, B. 

Ein Überwachungssystem für den unbeaufsiohtigten "Betrieb 

der TR 440 

in: Angewandte Informatik Braunschweig 20(1978) Heft 12, 
Ss. 526 - 528 


Knop, Jan;  Stichtenoth, Horst; Haverkamp, Wilhelm 

Organisation der automatisierten Datenverarbeitung an 'Hooh- 

schulen in Nordrhein-Westfalen 

in: data zeport Berlin(West), München 15(1980) Heft 4, 
Ss, 19-2 


Kool, Horst j 

Die Eignungsuntersuchung von Rechenzentrums-Personal 

in: Dan. NOOBenaen rm München, Wien 6(1983) Heft 1, 
5% m 50 


/23/ 


/24/ 


/25/ 


/26/ 


/21/ 


/28/ 


/29/ 


/30/ 


6-73 


Kroß, Günter 

SPOOL 2.0 - System zur Unterstützung eines zeitweise 

bedienungsunabhängigen Betriebes an ESER-Rechnern 

in: Berliner Informatik-Tage bit'82, 28. Juni bis 2. Juli 
1982, Tagungabericht, Humboldt-Universität zu Berlin, 
Organisations- und Rechenzentrum; Berlin 1982, 
S. 485 — 490 


Löffler, H. 

Ziele, Methoden und Probleme der Analyse komplexer Infor- 

mationssysteme 

in: Vorträge zur Analyse in EDVA und IV-Systemen, Problenm- 
seminar des Weiterbildungszentruns für Mathematische 
Kybernetik und . Rechentechnik / Informationsver- 
arbeitung; Technische Universität Dresden; Heft 53/80, 


S. 3-13 
Manuel, Tom 
MoAuto:s the good life for computers 
in: Blectronios New York 54(1981) Heft 11, S. 98 - 99 
Meier, Hermann Walter 


Recohnernetz DELTA Konzept, erste Einsatzvariante und 

Dienste 

in: Beehenischnik Datenverarbeitung Berlin 20(1983) Heft 6, 
S. er 11 


Meißler, Hans-Günter 

Gutaohten zum Pilotsystem bedienerarne Reohnernutzung 
- SPOOL 3 - 

Martin-Luther Universität Halle-Wittenberg; Organisations- 
und Rechenzentrum; Halle-Wittenberg 1983 


Meißler, Hans-Glünter 

SPOOLRJE* — eine Fernverarbeitungskomponente des, SPOOL- 

Systems 

in: Berliner Informatik-Tage bit'82, 28. Juni - 2. Juli 
1982, Tagungsbericht, Humboldt-Universität zu Berlin, 
Organisations- und Reohenzentrun; Berlin 1982, 
Ss. 491 — 497 


Mertens, B.; Hoßfeld, F. 

Jobsteuerung und Überwachung in einem wissenschaftlichen 

Rechenzentrum 

in: GI — 9. Jahrestagung Bonn 1. -— 5. Oktober 1979, Infor- 
natik Fachberiohte Band 19; Böhling, K. H.; 
Spies, P. P. (Hrsg.), Springer-Verlag Berlin(West), 
Heidelberg, New York 1979, S. 545 - 555 


Muchsel, Reginald 

Kontingentierung und Ressourcenverteilung an Hochschul- 

reohenzentren 

in: Das Rechenzentrum München, Wien 6(1983) Heft 3, 
5. 172 - 181 


/31/ 


/32/ 


/33/ 


/34/ 


/35/ 


/36/ 


/37/ 


/38/ 


6-74 + 
Näther, Bernd 
Ein Beitrag zur Erhbhung der Effektivität der Teohnologie 
und Organisation von Rechenzentren mit ESER-Reohenteohnik 
Dissertation, Ingenieurhoohsohule Dresden 1981 


O'Neill, Paul 


-Unattended Operations Using OPC 


in: Dan. Rechenzentrum München, Wien 4(1981) Heft 2, 
S. 3-9 


Pfeiffer, Peter 

Automatisierung der Technologie - Mittel zur Rationalisie- 
rung 

in: Piechentechnik Datenverarbeitung Berlin 20(1983) Heft 2, 


Piens, Conrad 

Befektivitätsuntersuohung für das System SPOOL 3 

in: Berliner Informatik-Tage bit'82, 28. Juni bis 2. Juli 
1982 Tagungsbericht, Humboldt-Universität zu Berlin, 
art Wer Tu und Reohenzentrun; Berlin 1982, 
S. 498 — 502 


Pinus, Rudolf; Mathauser, Pavel 

Brandsohutztechnische Maßnahmen in Rechenstationen . 

in: Brandschutz Explosionssohutz, Aus Forschung und 
Praxis 4 Staatsverlag der Deutschen Demokratischen Re- 
publik; Berlin 1980, S. 143 - 189 


Pralle, H. 
Auswirkungen der organisatoriscohen und technischen Entwick- 
lungstendenzen auf Großrechenzentren 


in: Organisation und Betrieb von Rechenzentren, 
Fachgespräch der GI, Erlangen, 12./13. März 1981, In- 
formatik Fachberichte Band 46; Springer-Verlag 


Berlin(West), Heidelberg, New York 1981, Ss. 166 - 168 


Raokles, R. 

Der Betriebsablauf in einem Konzern-Rechenzentrum 

in: Betrieb von Rechenzentren (Workshop der Gesellschaft 
für Informatik Karlsruhe, 23. - 24. Septenber 1975); 
Schreiner, A, (Hrsg.); Informatik Faohberichte Band 2; 
Springer-Verlag Berlin(West), Heidelberg, New York 
1976, S. 73 - 104 


Riohter, Rudi 

Produktionsteohnologie im Reohenzentrum 

Schriftenreihe Informationsverarbeitung; Verlag die Wirt- 
schaft; Berlin 1979 


/39/ 


/40/ 


/41/ 


/u2/ 


/43/ 


/44/ 


/45/ 


/46/ 


6-75 
Rippel, G.; Jasper, E.; Kneip, W\. 
Massenspelohersystenme -— ein erster Sohritt auf dem Weg zum 
operatorlosen Betrieb = ö 
in: Organisation und Betrieb von Rechenzentren, 
Fachgespräoch der GI, Erlangen, 12./13. März 1981, 
Brauer, W. (Hreg.); Informatik Faohberichte Band 46; 
Springer-Verlag Berlin(West), Heidelberg, New York 
1981, S. 176 - 187 


Sack, Kurt 

Zentral, dezentral oder kombiniert? Eine Betrachtung zum 

Inhalt und zu Entwicklungstendenzen von Organisationsformen 

der Datenverarbeitung 

in: Rechentechnik Datenverarbeitung Berlin 17(1980) 
Heft 10, S. 17 - 18 


Schiller, Hans-Jürgen 
Ein Beitrag zur Erhöhung des Jobdurchsatzes bei Multipro- 
gramm Betrieb für mittlere und große EDVA mit einem Rechen- 


‚werk 


Dissertation, Technische Universität Dresden, Fakultät für 
Elektrotechnik und Elektronik; Dresden 1977 


Schmitz, P. 

Zukünftige Nutzungsform der ADV im Hochsohulbereich 

in: Angewandte Informatik Braunschweig 2001978) Heft 5, 
S. 194 - 202 ‚ 


Schmitz, Paul; Krekel, Dietrich 

Aufgabenorientiertes Modell zur Nutzung der automatisierten 

Datenverarbeitung im Hochschulbereich (teil 1 und Teil 2) 

in: Das Reohenzentrum Hünchen, Wien 5(1982) Heft 2, 
S. 110 - 125; 5(1982) Heft 3, S. 142 - 158 


Seibt, Dietrioh 

Software zur Unterstützung von Reohenzentrumsfunktionen 

in: Angewandte Informatik Braunschweig 24(1982) Heft 2, 
Ss. 104 — 114 i 


Seibt, Dietrich; Langen, Bernhard; Barthel, Andreas; 
Kirchhtfer, Klaus 

Erhebung zur statistisohen Planung der Dienstleistungen von 
Servioe-Recohenzentren 

Teil A: Auswertung der postversandten Fragebögen 
BIFOA-Arbeitspapier 80AP8 (Zugleich Bericht Nr. 1 des 
Projektes SEDIS),; Köln 1980 


Siefarth, Gerhard 

Neue Maßstäbe für eine moderne Leitungstätigkeit 

in: Bechante-iik Datenverarbeitung Berlin 16(1979) Heft 3, 
S. 4 = 17 


/u1/ 


/u8/ 


/49/ 


/50/ 


/51/ 


752/ 


/53/ 


/5h/ 


755/ 


6-76 
Sitta, Heinz-Günter 
Untersuchung zur Bestimmung und Analyse von KEinflußgrößen 
bei Störungen im Produktionsprozgeß am Beispiel der 
ESER-Anlage im VEB DVZ Halle ; 
Diplomarbeit, Martin-Luther-Universität Halle-Wittenberg, 
Sektion Wirtscohaftswissenschaften; Halle 1980 


Stuchlik, Franz; VWerler, Karl-Heing 

Zur Entwicklung neuer Technologien geistiger Arbeit 

in: Wissenschaftliche Zeitschrift der Technischen Hoch- 
'sohule au von Guerioke" Magdeburg 27(1983) Heft 3, 
s.93-9 


Wähner, Gerd 


Grundsätze und Methoden zur reohnergestützten Planung und 
Analyse der Auslastung von EDVA des ESER im kurzfristigen 
Planungszeitraum = 
Inaugural-Dissertatich, Hochsohule für Ökonomie "Bruno 
Leuschner"; Berlin 1978 


Wähner, Gerd 
Organisation der Bedienung von EDVA 
ins Reohenteohnik Datenverarbeitung Berlin 19(1982) Heft 1, 


Wall, Dieter 

Der organisatorische Gestaltungsspielraun des Rechenzem- 
truns bei den Betriebsarten Stapel- und Dialogverarbeitung 
in: Ee hie ‚München, Wien 6(1983) Heft 1, 


Winks, Hans 

SPOOL -— ein Systen zur Automatisierung von Produktions- 

prozessen an BSER-Rechnern; Entwioklungsstand und Entwick- 

lungsriohtungen 

in: Berliner Informatik-Tage. bit'82, 28. Juni bis 2. Juli 
1982, Tagungsberioht, Humboldt-Universität zu Berlin, 
Orsanisations- und Rechenzentrun; Berlin. 1982, 
5. 0 Au: 57 


Wolf, F. 

Das Rechenzeit-Abrechnungsverfahren an der Universität 

Erlangen-Nürnberg 

in: Abrechnung "von Reohenzentrums-Dienstleistungen; 
Mertens, Peter (Hrsg.), Applied Computer Soienoe, Be- 
riohte zur praktischen Informatik 12, Carl Hanser Ver 
lag München, Wien 1978, S: 133 — 144 


0. N 

Computer sohaltet sich selbst ein 

in: Siemens data report Berlin, Münohen 18(1983) Heft 6, 
S. 39 


o. N. 

In eigener Saohe 

in: Login — Informationsscohrift des Hochsohulreohenzentrums 
Gießen 2(1981) Heft 2, S. 19 - 20 


Verfasser: 


Prof, Dr. rer. nat. Franz Stuchlik 
Dipl.-Ing. Werner Winzerling 

Technische Hochschule "Otto von Guerioke" 
Sektion Reohentechnik / Datenverarbeitung 
3010 Magdeburg 

Boleslaw-Bierut-Platz-5 

Tel: Mgb. 592805 


Sommerfeld, Michael e=78 


Simulation der Ressourcenauslastung und des Jobdurchsatzes eines 
Rechnersystens unter dem Betriebssystem 0OS/MVT und dem 


Preschedulingsystem SPOOL 


1. Motivation der Fragestellung 
Intuitive Festlegungen der Hardwarestruktur, der Betriebssysten- 


funktionen und der Produktionstechnologien reichen nicht mehr 
aus, um die Leistungsmöglichkeiten heutiger und zukünftiger 
Rechnersysteme effektiv nutzen zu können. Deshalb gewinnt 

die Annendung von Realisierungen mathematischer Modellklassen, 
auf die sich wesentliche Eigenschaften der Rechnersystene 
abbilden lassen, zunehmend an Bedeutung. Beispiele für Reali- 
sierungen solcher Modellklassen sind die Simulationssystene 
SIMDIS, GASPIV, SIMKONM-F und -3, Realisierungen der S-, E- und 
Pro-Netze und das in Entwicklung befindliche System MARS. 

Etwas eingeschränktere Modellierungsmöglichkeiten bieten 
gegemnärtig nooh Anwendungen der Bedienungstheorie und der 
hybriden Simulation (/1/, /2/). 

Am ORZ der Humboldt-Universität wird das System SPOOL ent- 
wickelt, das durch die Beseitigung verschiedener Schwachstellen 
des OS/MVT die bessere Bedienbarkeit und effektivere Aus- 
lastung entsprechender Rechnersysteme ermöglicht. Die ge- 
eignete Nutzung von SPOOL hängt jedoch von vielen Faktoren 

ab. Solche wären z. B« geeignete Hardware des Rechnersysteng, 
angepaßte Generierung des OS/MVT und des Systems SPOOL wie 
auch Festlegung einer günstigen Produktionstechnologie. Die 
Simulation der Ressourcenauslastung eines Rechnersyatens unter 
Berücksichtigung derartiger Faktoren wird die Bestimmung von 
Engpässen und teilweise deren zielgerichtete Entschärfung er- 
möglichen. Die Simulation bietet sich zur Lösung dieser Auf- 
gabe an, da Ergebnisse handhabbarer bedienungstheoretischer 
Modelle, wegen des nicht konstanten Jobprofils und der 
prioritätsbezogenen Vergabe der CPU, anzuzweifeln sind (/1/). 
Zur Modellierung wurde das System MARS (Modellierung und Analyse 
von Rechner- und Steuersystemen), das gegenwärtig am Bereich In- 
formationsverarbeitung der Sektion Mathematik der HUB imple- 
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mentiert wird, ausgewählt. 


2. Erläuterung des Modells 
2.1. MARS /3/ 


Das System MARS ermöglicht die Auswertung von M-Netzen 
(modifizierte zeitbewertete Petri-Netze). Von Petri-Netzen 
unterscheiden sich diese durch attributierte Marken, Feuer- 
zeiten, konfliktlösende Transitionsprozeduren, marken- 
attributändernde Transitionsprozeduren, komplexere Struktur 
der Transitionen, durch Realisierung der Plätze als FIFO- 
Warteschlangen und die Nutzungsmöglichkeit lokaler und glo- 
baler Variablen, 

Die komplexere Struktur der Transitionen besteht in der Mög- 
lichkeit der Gruppenbildung von Eingangspfaden bzw. Ausgangs- 
pfaden, die durch einen die Pfade verbindenden Querstrich 
dargestellt wird. Von den Gruppen ist jeweils genau eine der 
_Eingengsgruppen und eine der Ausgangsgruppen an jedem Feuern 
beteiligt. Pfade, die nicht durch Querstriche gekennzeichnet 
sind, sind immer am Feuern beteiligt. Eine Transition kann 
erst dann wieder neu aktiviert werden, wenn die Feuerzeit der 
letzten Aktivierung abgelaufen ist und mindestens eine Feuer- 
möglichkeit besteht. 

Das System MARS wird vollständig in PASCAL implementiert. 
Gegenwärtig ist die Modellierung durch das Fehlen eines Pre- 
compilers und die Wiedergabe der Systemzeit durch eine 
Variable des Typs SHORTINT erachnert. 


2.2. Eingabedaten des Modells 

Ein aus SMF-Daten des Produktionsbetriebs erzeugter abstrakter 

Jobstapel stellt die Eingabe des Modells dar. Jeder abstrakte 

Job wird während der Abarbeitung des M-Netzes einer Marke zu- 

gewiesen, mit der er das Netz durchläuft. 

Ein abstrakter Job beinhaltet: 

- Readerzeit (Verneilzeit des Jobs im SPOOI- und im OS-Reader 
sowie den SPOOI-Checkprozessoren) 

- Stepanzahl (auf maximal 5 Steps begrenzt - Verbrauchswerte 
für weitere Steps fortlaufend auf die ersten 5 
addiert) 


L44 (0) © 


C) Excws 
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Druckzeilenanzahl (Formate nicht unterschieden) 

Kartenanzahl (geschätzter Wert, da SMF-Daten über die 
Aktivitäten des Systems SPOOL nicht aufge- 
zeichnet werden) 

Jobklassen (durch maximalen HS-Bedarf bestimmt) 

- Jobnumner 


Stepbezogene Angaben: 

- Hauptspeicherbedarf 

- CPU-Zeit 

Anzahl der E/A für 

. Plattenstrecke (Selektorkanal 1) 

. Bandstrecke (Selektorkanal 2) 

. Drucker, Kartenleser (Multiplexkanal) 
Anzahl angesprochener Dateien 

- Anzahl angesprochener Magnetbänder 
Stepinitlalisierungszeit 


/ı 


2.3. Kodellstruktur s 

Das abgebildete Netz des Rechnersystemmodells besteht aus einem 
Readerprozeß, einer CPU, 2 Selektorkanälen, einem Multiplex- 
kanal, 3 Nutzerprogrammregionen, 2 Druckprozessen, einen 
Jobstrom der aus bis zu 7 verschiedenen Jobklassen bestehen 
kann, .und 5 CPU-Auswahlprioritäten, von denen die beiden 
höchsten für SPOOL und OS/NVT reserviert sind. 

Die Transition T14 und die Plätze Li und RDRWS dienen ledig- 
lich der kontinuierlichen Versorgung des Readerprozesses mit 
einer zuvor festgelegten Anzahl von Marken. Deshalb ist der 
Readerprozeß nur in einer Anfangsphase aktiv. 

Das Teilnetz, bestehend aus den Transitionen T17, T18, T19, 
T6, MPLEA, MBEA und DSKEA sowie den von ihnen eingeschlossenen 
Plätzen modelliert die Vergabe der CPU und der Kanäle an die 
System- und die Nutzeraufgaben. Dabei stellen die Gesant- 
feuerzeiten der Transitionen T6, MPLEA, MBEA bzw. DSKEA die 
Auslastungen der CPU, des Multiplexkanals, des Selektorkanals | 
für die Nagnetbandstrecke bzw. des Selektorkanals für die 
Plattenstrecke dar. Die Wartezeiten der Aufgaben lassen sich 
aus den Auswertungsgrößen Belegungsdauer und durchschnitt- 
liche Belegungszahl der Plätze 132 vis L36, SLI, SL2 und 

MPL ermitteln. j 
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Der noch nicht genauer erklärte Teil des Netzes realisiert 
die Auswahl der Jobs bzw. Jobsteps für die einzelnen Phasen 
der Abarbeitung. So wird mit dem Feuern von Ti der Reader- 
prozeß aktiviert, der beim Feuern von T2 für den ent- 
sprechenden JOB beendet ist. Die mit der Tranaition T3 
verbundenen Plätze stellen die nach Klassen organisierte / 
Ausführungswarteschlange dar. T3 stellt dabei die Ordnung 
nach Jobklassen her. 

T4 versorgt die 3 Initiatoren für Nutzeraufgaben, deren 
Steuerung zwischen T4 und dem Platz PRWS dargestellt ist, 

mit Marken. Nehmen wir an, daß T4 eine Marke gedoppelt 

und auf die Plätze L9 und L45 gebracht hat. Der Platz 145 
zeigt an, daß der entsprechende Initiator belegt ist. Zur 
selben Zeit wird damit T7 feuerbereit und bewegt die Marke 
von L9 entweder auf 148 (falls nicht genllgend zusammen- 
hängender Hauptspeicherplatz für die Stepausführung verfüg- 
bar ist) oder doppelt sie und bewegt sie auf die Plätze 

RG1 und L18. Kommt die Marke von L18 schließlich aus dem 
CPU-E/A-Zyklus auf den Platz 121, so wird T10 feuerbereit. 
T10 bewegt die Marke auf 151, falls der letzte Step abge- 
arbeitet worden war oder sonst auf 19, womit eine neue 
Stepinitiierung beginnt. Die Transition T22 verzögert eine 
Marke, die auf 148 gelangt ist, für eine gewisse Zeit, um 
ihr danach erneut den Test auf Verfügbarkeit von Hauptspeicher- 
platz zu ermöglichen. Mit dem Peuern der Transition 725 wird 
der Initiator wieder verfügbar, da L9 und 145 keine Marken 
mehr enthalten, wie auch das ganze Teilnetz, 

T13 verteilt die Druckausgaben der Jobs auf die beiden Drucker- 
prozesse bzw. Überführt sie in einen Wartezustand, falls kein 
Druckprozeß verfügbar ist. 


3. Validierung des Modells 
Zur Validierung des Modells wurden SMF-Daten, die am 


modellierten Rechnersystem aufgezeichnet wurden, zur Erzeu- 
gung von praxisnahen Jobströsen und parallel zur Bestimmung 
der realen Ressourcenauslastung und des vurchsatzverhaltens 
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ausgewertet. Um Verfälschungen der Ergebnisse zu vermeiden, 
wurden Zeitabschnitte betrachtet, an deren Grenzen kein Job 
im System aktiv war und innerkilb derer ständig mindestens ein 
Job ausgeführt wurde. Außerdem werden verschiedene Phasen 
des Stapelbetriebes wie Expreßbetrieb, bedienarmer Betrieb 
und Nachtschichtbetrieb untersucht werden. Wenn durch Modi- 
fikationen am Modell die Simulationsergebnisse hinreichend 
genau denen entsprechen, die aus den SMF-Daten ermittelt 
wurden, können die eigentlichen Ziele der Modellierung in 
Angriff genommen werden. 
Voraussagen Über die Ergebnisse einer Regionnormierung, 
modifizierter Jobklasseneinteilungen, veränderter SPOOL- 
Generierungsparameter, von Hardwareerweiterungen und Hard- 
wareänderungen zu erzielen, werden Ziele der weiteren Mo- 
dellierung sein. 


4. Grenzen der Ausdrucksfähigkeit und Effizienzprobleme . 
Nicht alle wesentlichen Einflußgrößen auf die Ressourcenaus- 


lastung und den Jobdurchsatz können so exakt wie die Summe 
der CPU-Zeiten und die der Kanalbelegungszeiten der Jobs 

im Modell berücksichtigt werden. Solche Einflußgrößen sind 
beispielsweise die innere Parallelität der Jobs, das reale 
Zeitverhalten der Jobs im Ausführzyklus, die Bedienaktionen. 
in der Produktion, die die SMP-Daten lieferte, Beschränkung 
auf die Widerspiegelung relativ kurzer Produktionsphasen 
und Vergröberung des Ausführungszyklus durch Zusammenfassung 
mehrerer E/A zu einer einzigen. Die letzten beiden Ein- 
schränkungen sind nötig, um die Rechnerbelastung durch die 
Simulation in vertretbaren Grenzen zu halten. Zur Berlick- 
sichtigung der anderen Größen können nur Erfahrungswerte 
herangezogen werden. Eine erhöhte innere Parallelität von 
Jobs führt zu einer höheren Ressourcenauslastung und damit 
bei 'gleichen quantitativen Lasten für die Ressourcen zu er- 
höhtem Jobdurchsatz. Somit könnte der relative Unterschied 
zwischen der realen Ausführung nur eines Jobs und dessen 
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simulierter Ausführung weitgehend als ‘Maß seiner inneren 
Paxllelität angesehen werden. 
Bei der parallelen Ausführung mehrerer Aufgaben hat das 
Zeitverhalten und die Priorität jeder einzelnen Einfluß auf die 
Ressourcenauslastung. Durch geeignete Wahl von Zufallszahlen- 
generatoren zur Festlegung der Belegungsdauer der einzelnen 
Ressourcen wird es möglich sein, eine gute Näherung zu 
erreichen. Doch wird sich auf jeden Fall die Tatsache, daß 
das Modell der CPU gegenwärtig noch nicht unterbrechbar ist, 
negativ auf den Auslastungsgrad der Ressourcen im Multi- : 
programmbetrieb auswirken. Erst wenn dlese Unterbrechbar- 
keit realisiert ist, werden sinnvolle Ergebnisse der Simu- 
lation einer dynamischen Prioritätensteuerung zu erwarten 
sein. Bei derAuswertung der Simulationsergebnisse kann dieser 
Mangel gegemnärtig nur durch einen Korrekturfaktor berück- 
sichtigt werden. Das beschriebene Modell besteht aus 82 
Steuerkarten zur Netzgenerierung und etwa 700 PASCAIl»-Zeilen. 
Dieser Aufwand ließe sich um 20 % verringern, wenn die M-Netze 
nicht nur FIFO-Warteschlangen unterstützen würden. Auch ist 
ebsehbar, daß die Realisierung einer durch mehrere Pri- 
oritätsklassen unterbrechbaren CPU zu einem aufwendigen Teil- 
netz führt, womit das Modell weiter aufgebläht und die 
Effizienz stark herabgesetzt würde. Durch Einbau eines 
geeigneten analytischen Modells für den CPU-E/A-Zyklus 
könnte das Effizienzproblem gelöst werden. Ein solcher Ein- 
bau ist aber im Konzept des Systems MARS nicht vorgesehen 
und deshalb eher in einem hybriden oder kombinierten Simu-" 
lationssystenm erreichbar. 
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Möglichkeiten portabler Basissoftware 


Mit den UNIX-Systen ist ein Betriebssystem weit verbreitet, 
dae für 16-Bit-Prozessoren implementiert wurde, aber in- 
zwischen auch auf 32-Bit-Prozessoren übertragen wurde, Weni- 
ger bekannt ist das THOTH-Systen, das ebenfalls für 16-Bit- 
Prozessoren geschaffen wurde und inzwischen auf 6 verschiede- 
nen Mikrorechnern angewendet wird, 


Grundlage dieser portablen Betriebssysteme sind Sprachent- 
wicklungen. (C und ZED), die besonders auf Bedürfnisse der 
Systenprogrammierung abgestimmt sind, aber als höhere Pro- 
granniersprache hinreichende Distanz zu Maschinenabhängig- 
keiten aufweisen. Die Verfügbarkeit ‘von Compilern für diese 
Sprachen auf geeigneten, in der DDR verfügbaren "echnern 
gibt die Möglichkeit der Übertragung dieser Systeme. 

UNIX und THOTH sind Modellfälle für portable Basissoftware,. 
Sie werden im Rahmen des Beitrages kurz charakterisiert 

und es werden die Architekturprinzipien erläutert. 


Dipl.-Math. H. Winks 
Humboldt-Universität Berlin, ORZ 
1086 Berlin 
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